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

Committed: https://crrev.com/25fdbad21c66328e5ada9b9b436d3a8c146ca728
Cr-Commit-Position: refs/heads/master@{#408869}

[esprehn, 2016-07-29 21:57:19]

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 convertable types.
==========

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

[esprehn, 2016-07-29 21:57:21]

The CQ bit was checked by esprehn@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-29 21:57:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[esprehn, 2016-07-29 22:03:14]

esprehn@chromium.org changed reviewers:
+ haraken@chromium.org, yutak@chromium.org

[esprehn, 2016-07-29 22:04:28]

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

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

[commit-bot: I haz the power, 2016-07-29 23:51:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-29 23:51:23]

Dry run: This issue passed the CQ dry run.

[haraken, 2016-07-30 04:51:17]

LGTM

[esprehn, 2016-07-30 07:32:51]

The CQ bit was checked by esprehn@chromium.org

[commit-bot: I haz the power, 2016-07-30 07:33:00]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-30 07:37:21]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-30 07:38:41]

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

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

Committed: https://crrev.com/25fdbad21c66328e5ada9b9b436d3a8c146ca728
Cr-Commit-Position: refs/heads/master@{#408869}
==========

[commit-bot: I haz the power, 2016-07-30 07:38:42]

Patchset 1 (id:??) landed as
https://crrev.com/25fdbad21c66328e5ada9b9b436d3a8c146ca728
Cr-Commit-Position: refs/heads/master@{#408869}