StringBuilder::append should not use reserveCapacity.

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

Committed: https://chromium.googlesource.com/chromium/src/+/e3ca90f12717b30d69489e5bb446f72585d345be

[esprehn, 2016-08-25 17:15:16]

Description was changed from

==========
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
==========

to

==========
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
==========

[esprehn, 2016-08-25 17:21:59]

Description was changed from

==========
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
==========

to

==========
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

Committed:
https://chromium.googlesource.com/chromium/src/+/e3ca90f12717b30d69489e5bb446...
==========

[esprehn, 2016-08-25 17:22:02]

Committed patchset #1 (id:1) manually as
e3ca90f12717b30d69489e5bb446f72585d345be.