New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 640598 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

StringBuilder::append is n^2 when appending 8bit strings to 16bit buffers

Project Member Reported by esprehn@chromium.org, Aug 24 2016

Issue description

This was caused by:
https://codereview.chromium.org/2046353002

And fixed by:

https://codereview.chromium.org/2192293002

But it missed the 53 branch cut. As a result loading very large JS files that contain Unicode characters in Chrome 53 is extremely slow (ex. One Vivaldi engineer reports a 10x slowdown).

We should merge this to 53. 
 
Cc: seththompson@chromium.org hablich@chromium.org

Comment 2 by gov...@chromium.org, Aug 24 2016

Before we approve merge to M53, Could you please confirm whether this change is well baked/verified in Canary and safe to merge? Please note that M53 is very close to Stable launch so bar is very high. We will take this change ONLY if it is important and safe. Thank you.
Yes this has baked for 3 weeks and is very safe.

Comment 4 by gov...@chromium.org, Aug 24 2016

Labels: -Merge-Request-53 Merge-Approved-53
Approving merge to M53 branch 2785 based on comment #3. Please merge ASAP. Thank you.
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 25 2016

Labels: -merge-approved-53 merge-merged-2785
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e3ca90f12717b30d69489e5bb446f72585d345be

commit e3ca90f12717b30d69489e5bb446f72585d345be
Author: Elliott Sprehn <esprehn@chromium.org>
Date: Thu Aug 25 17:16:13 2016

StringBuilder::append should not use reserveCapacity.

reserveCapacity allocates the exact capacity specified which means
when we had a 16bit buffer in StringBuilder and were appending 8bit
strings to it we were constantly reallocating and copying the buffer.

Instead we can just call Vector::append() directly since it has a
template overload that can accept implicitly convertible types.

I noticed this when looking at lever.co's web app loading in
Instruments, it was spending 15% of the main thread time inside
TextResource::decodedText which was 83% memmove, and 11% munmap.

Switching to Vector::append should restore the correct size
doubling behavior when appending LChars to a UChar StringBuilder
and make this much faster.

This was a regression from when I switched to using a Vector
inside StringBuilder in:
https://codereview.chromium.org/2046353002

Review-Url: https://codereview.chromium.org/2192293002
Cr-Commit-Position: refs/heads/master@{#408869}
(cherry picked from commit 25fdbad21c66328e5ada9b9b436d3a8c146ca728)

BUG= 640598 
TBR=govind@chromium.org

Review URL: https://codereview.chromium.org/2280723002 .

Cr-Commit-Position: refs/branch-heads/2785@{#749}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/e3ca90f12717b30d69489e5bb446f72585d345be/third_party/WebKit/Source/wtf/text/StringBuilder.cpp

Status: Fixed (was: Available)
Cc: yn...@vivaldi.com

Sign in to add a comment