You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I understand that using JSON-B can have a significant hit on performance. IIUC, Yasson (the reference implementation of JSON-B) was not designed with speed in mind, so Jackson is orders of magnitudes faster, but not compatible to JSON-B (IIRC, there was an initiative to make it a JSON-B implementation, but I assume that project has vanished).
But if I'm not mistaken, both Yasson and Jackson use reflection to do the binding. This is not very Quarkus-ish, is it? I just stumbled over a project called dsl-json, which works as an annotation processor to create the actual binding code. And they claim to be magnitudes faster than Jackson! They even have some JSON-B compatibility, but I haven't evaluated how far that goes; nor for what version of JSON-B.
What do you all think of implementing a Quarkus extension that does this or something similar, so Quarkus could benefit from the compile-time optimisation with regards to CPU und memory usage also when (de)serializing from/to JSON?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I understand that using JSON-B can have a significant hit on performance. IIUC, Yasson (the reference implementation of JSON-B) was not designed with speed in mind, so Jackson is orders of magnitudes faster, but not compatible to JSON-B (IIRC, there was an initiative to make it a JSON-B implementation, but I assume that project has vanished).
But if I'm not mistaken, both Yasson and Jackson use reflection to do the binding. This is not very Quarkus-ish, is it? I just stumbled over a project called dsl-json, which works as an annotation processor to create the actual binding code. And they claim to be magnitudes faster than Jackson! They even have some JSON-B compatibility, but I haven't evaluated how far that goes; nor for what version of JSON-B.
What do you all think of implementing a Quarkus extension that does this or something similar, so Quarkus could benefit from the compile-time optimisation with regards to CPU und memory usage also when (de)serializing from/to JSON?
Beta Was this translation helpful? Give feedback.
All reactions