[
https://issues.apache.org/jira/browse/SOLR-15560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17397632#comment-17397632
]
Mark Robert Miller commented on SOLR-15560:
-------------------------------------------
So this is about the end of the road. Not a large difference from last results,
but I've been hardening and improving the benchmark a bit and focusing on
related items and checks that won't necessarily pop in this focused benchmark.
I've done a bit to keep the benchmark from putting it's thumb on the brake and
so that is why you see some improvement in the before numbers for encode, but
the after encode still took a larger gain. I've tried to give the before
results every chance and advantage to creep up with many of the benchmark
changes, but they are pretty happy at that level.
At this point, the fulcrum has moved elsewhere, there may even be a tweak or
two that can come out. Still doing a bit of vetting and there are likely some
items that could use comment, iteration, but precommit should be passing, tests
should be passing, and things should be looking fairly good.
||#||Benchmark||Params||Mode/Unit||Score||Error||
|0|JavaBinBasicPerf - decode +{color:#00875a}1099{color}%|docCount=50|thrpt in
ops/s|before: {color:#505f79}118{color}
after: {color:#00875a}1,415{color}|{color:#de350b}2{color}
{color:#de350b}126{color}|
|1|JavaBinBasicPerf - encode +{color:#00875a}465{color}%|docCount=50|thrpt in
ops/s|before: {color:#505f79}162{color}
after: {color:#00875a}915{color}|{color:#de350b}1{color}
{color:#de350b}46{color}|
!javabin.encode.decode.summary.png!
!javabin.encode.decode.compare.png!
> 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
>
> Time Spent: 40m
> 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]
