• Benedikt Meurer's avatar
    [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
    Benedikt Meurer authored
    This change significantly improves the performance of string
    concatenation in optimized code for the case where the resulting string
    is represented as a ConsString. On the relevant test cases we go from
    
      serializeNaive: 10762 ms.
      serializeClever: 7813 ms.
      serializeConcat: 10271 ms.
    
    to
    
      serializeNaive: 10278 ms.
      serializeClever: 5533 ms.
      serializeConcat: 10310 ms.
    
    which represents a 30% improvement on the "clever" benchmark, which
    tests specifically the ConsString creation performance.
    
    This was accomplished via a couple of different steps, which are briefly
    outlined here:
    
      1. The empty_string gets its own map, so that we can easily recognize
         and handle it appropriately in the TurboFan type system. This
         allows us to express (and assert) that the inputs to NewConsString
         are non-empty strings, making sure that TurboFan no longer creates
         "crippled ConsStrings" with empty left or right hand sides.
      2. Further split the existing String types in TurboFan to be able to
         distinguish between OneByte and TwoByte strings on the type system
         level. This allows us to avoid having to dynamically lookup the
         resulting ConsString map in case of ConsString creation (i.e. when
         we know that both input strings are OneByte strings or at least
         one of the input strings is TwoByte).
      3. We also introduced more finegrained feedback for the Add bytecode
         in the interpreter, having it collect feedback about ConsStrings,
         specifically ConsOneByteString and ConsTwoByteString. This feedback
         can be used by TurboFan to only inline the relevant code for what
         was seen so far. This allows us to remove the Octane/Splay specific
         magic in JSTypedLowering to detect ConsString creation, and instead
         purely rely on the feedback of what was seen so far (also making it
         possible to change the semantics of NewConsString to be a low-level
         operator, which is only introduced in SimplifiedLowering by looking
         at the input types of StringConcat).
      4. On top of the before mentioned type and interpreter changes we added
         new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
         CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
         checks.
    
    There are several more improvements that are possible based on this, but
    since the change was already quite big, we decided not to put everything
    into the first change, but do some follow up tweaks to the type system,
    and builtin optimizations later.
    
    Tbr: mstarzinger@chromium.org
    Bug: v8:8834, v8:8931, v8:8939, v8:8951
    Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
    Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
    Doc: https://bit.ly/fast-string-concatenation-in-javascript
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
    Commit-Queue: Michael Achenbach <machenbach@chromium.org>
    Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
    Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
    Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
    Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#60318}
    d6a60a0e
type-hints.h 1.65 KB