New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possibly measure benefits of Jackson Afteburner module: https://github.com/FasterXML/jackson-module-afterburner #1

Closed
cowtowncoder opened this Issue Jul 6, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@cowtowncoder
Copy link

cowtowncoder commented Jul 6, 2014

First of all, thank you for this test benchmark. I think it is great to have independent verification of benefits (time/space) of various serialization options.

One thing that might make sense is to consider use of Jackson Afterburner module (https://github.com/FasterXML/jackson-module-afterburner). It uses bytecode generation to further optimize access to Bean data, and can speed ser/deser by additional 20-30%.
Although in general I think it is best to compare "vanilla" settings, afterburner requires only one line of registration, so I think it is still reasonably easy option to add. But if used, it should probably be reported separate from basic stock Jackson databinding module.

@egillespie egillespie self-assigned this Feb 27, 2015

@egillespie

This comment has been minimized.

Copy link
Owner

egillespie commented Feb 27, 2015

I added some measurements for Jackson Afterburner. The results seem questionable but that could be due to the old hardware I ran the tests on today.

I pushed the addition anyway and will rerun the benchmarks on the hardware used for the original benchmarks as soon as I can.

@cowtowncoder

This comment has been minimized.

Copy link
Author

cowtowncoder commented Feb 27, 2015

Right, results would suggest that Afterburner either was not registered, or that test does not exercise regular databinding functionality for some reason. I can try to see which one is likely.

@cowtowncoder

This comment has been minimized.

Copy link
Author

cowtowncoder commented Feb 27, 2015

Ok. The reason is actually bit different: it's because code uses @JsonCreator for passing arguments. Afterburner currently only optimizes field/setter access, and use of default (no-args) constructor. This may be changed in future, but for now it means there's no benefit for this particular test case.

One suggestion for test itself: StandardObjectMapper disables MapperFeature.CAN_OVERRIDE_ACCESS_MODIFIERS. This may have non-trivial negative effect, because JDK has somewhat heavy checking of access rights and will add to reflection overhead.
I wrote about this few years back:

http://www.cowtowncoder.com/blog/archives/2010/04/entry_396.html

and this is the reason for defaulting to change access right; not because of actual access but because of significant performance penalty. You may want to at least see if it has big effect -- in my tests it did affect things regardless of access levels, so even public access was affected.

@egillespie

This comment has been minimized.

Copy link
Owner

egillespie commented Feb 27, 2015

Thanks for the feedback. I'll double-back and follow through with your original suggestion of measuring the performance using the default configurations of each framework.

@egillespie

This comment has been minimized.

Copy link
Owner

egillespie commented Feb 27, 2015

I pulled out anything that was overriding Jackson default behavior and saw some good performance improvements (Jackson serialization is consistently 2x faster than it was this morning when I updated the benchmarks!). Deserialization using Afterburner is now ~20% faster than vanilla Jackson too.

If all looks well to you, I'll close this issue.

@cowtowncoder

This comment has been minimized.

Copy link
Author

cowtowncoder commented Feb 27, 2015

Cool, great that you were able to see changes in numbers. Serialization especially is affected by reflection overhead, as there's bit less to do afterwise. And Afterburner does work there since access is via getters and/or fields.

@egillespie

This comment has been minimized.

Copy link
Owner

egillespie commented Feb 27, 2015

Yeah, it's been an educational day for me!

@egillespie egillespie closed this Feb 27, 2015

@cowtowncoder

This comment has been minimized.

Copy link
Author

cowtowncoder commented Feb 27, 2015

One other idea: I need to add bit more explanation for that MapperFeature too, adding performance implications. I can see why it would seem like a good idea to disable it from security perspective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment