Details
-
Sub-task
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
Javabin performance can be pretty impactful on search side scatter / gather and especially the /export handler.
It turns out, in JavaBin, where it does a large switch to dispatch based on the type, its a hot spot that is too large to be inlined.
You can pull some less common paths out into another method to address this.
I have not benchmark this yet, and it’s possible other bottlenecks may dampen the win, but I noticed the following on ref branch (with a couple other optimizations that were not nearly as wide affecting or quite as hot):
When you run the tests, you get the best results in “client” mode - eg you prevent the C2 compiler from kicking in. Let’s say I could run the core nightly tests serially on my laptop in about 8 minutes with C1 - C2 might take another 2 to 3 minutes on top. This is because the work it does optimizing and compiling and uncompiling on such a diverse task ends up being the dominant performance drag.
With a bit of key optimization here, running the tests with C2 ends up about on par with stopping at C1, even though C2 still dominates everything else.
That’s a pretty impactful win in order to be able to move the needle like that.
Why such a win on C2 without C1 also dodging forward? It’s much more manageable to reduce the byte code for a none inlined hot method below the C2 size threshold for inlining than C1s.
So this should be a decent win i hope. There are a variety of differences that may outweigh it though.
- javabin on master has tail recursion.
- generates a tremendous number of byte arrays
- converts between utf8 and utf16
- manually does the encoding (the jvm can cheat)
- Has a number of classes that extend it (vs 1 here)
- lots of other things
I’m optimistic we can see some gain though.
Attachments
Attachments
Issue Links
- links to
