[ https://issues.apache.org/jira/browse/SOLR-15560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400871#comment-17400871 ]
Mark Robert Miller commented on SOLR-15560: ------------------------------------------- This should have been wrapped up by now, but a few things have slowed me down. One, I felt it best to heavily investigate any unexpected trade offs to these changes. That’s actually really hard to do legitimately. Two, being able to systematically explore a large range and space of the types and combinations that make up what JavaBin encodes/decodes in relative isolation is a pretty important step to really having confidence in a hand rolled single project codec like this. Currently, the unit tests for JavaBin simply pops a tiny fraction of some tiny contrived objects at it. So I’ve looked at this problem before, I’ve spent time on it. Bringing me to three: I figured I might as well do this right. I have a lot of time spent in the past looking into JavaBin work without cheating out on the effort really required. A lot of that work and effort dove tails with importantly test / benchmark stuff. So rather than just do the easy half way effort, I stepped back for a moment to do it right. I need these building blocks anyway - I don’t have the tracks and guardrails and tests and time and all the various things and tools and strategies that could keep me honest on the ref branch. > 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org