[
https://issues.apache.org/jira/browse/SOLR-15560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405509#comment-17405509
]
Mark Robert Miller commented on SOLR-15560:
-------------------------------------------
I am currently spinning some work in this issue out to a separate PR in
SOLR-15581.
Beyond that, I'm pretty close to being able to wrap this up. It spun up quite a
bit of work for being an item I chose for how quickly it could be knocked out,
but I have backlog of performance related issues and they are all facing a
similar crises - when working on the ref branch, I followed a trail - almost
like having training wheels, certain changes came at the right time and with
the right progress and ability to contain or testing and a variety of things
giving the ability to understand enough to be comfortable. Without that and
trying to create snippets of work of similar quality, I'm left in a position
that leaves even more effort per issue to verify, and a backlog of issues to
repeat that on. So each issue has led me down that path of helping alleviate me
from that future effort journey to some degree. JavaBin, being an issue with a
history of 'improvements' and resource usage changes tossed in with hardly the
care necessary (not really do to neglect, but the cost), I had to draw a bit of
line here on myself and both extensively investigate and verify, as well as set
myself up a bit more with I continue to need for the other issues I have
backlogging.
> Optimize JavaBinCodec encode/decode performance.
> ------------------------------------------------
>
> Key: SOLR-15560
> URL: https://issues.apache.org/jira/browse/SOLR-15560
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mark Robert Miller
> Assignee: Mark Robert Miller
> Priority: Minor
> Attachments: javabin.decode.1.before.json,
> javabin.decode.2.after.json, javabin.decode.before.and.after.compare.png,
> javabin.decode.before.and.after.summary.png,
> javabin.encode.before.and.after.compare.png,
> javabin.encode.before.and.after.summary.png,
> javabin.encode.decode.compare.png, javabin.encode.decode.summary.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
