Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Sub-task
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      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

        1. javabin.decode.1.before.json
          2 kB
          Mark Robert Miller
        2. javabin.decode.2.after.json
          2 kB
          Mark Robert Miller
        3. javabin.decode.before.and.after.compare.png
          33 kB
          Mark Robert Miller
        4. javabin.decode.before.and.after.summary.png
          42 kB
          Mark Robert Miller
        5. javabin.encode.before.and.after.compare.png
          30 kB
          Mark Robert Miller
        6. javabin.encode.before.and.after.summary.png
          37 kB
          Mark Robert Miller
        7. javabin.encode.decode.compare.png
          56 kB
          Mark Robert Miller
        8. javabin.encode.decode.summary.png
          60 kB
          Mark Robert Miller

          Activity

            People

            • Assignee:
              markrmiller Mark Robert Miller
              Reporter:
              markrmiller Mark Robert Miller

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 1h 50m
                1h 50m

                  Issue deployment