Bug 117781 – Consider using String rope for XMLHttpRequest.responseText

• Status: NEW
• Component: DOM

[Ryosuke Niwa]

Consider merging https://chromium.googlesource.com/chromium/blink/+/3d7d1c4f000b6a955ca23a17aa1bee48e8c281b3

MLHttpRequest#responseText should use a rope

Instead of building a flat WTF::String from XMLHttpRequest response data, we
should build a v8::String rope. That way when web sites query the responseText
field repeatedly, every query will share the same underlying data.

This CL causes StringImpl::hashSlowCase to drop way down the CPU profile of
reloading Mobile Gmail:

Before: 1.08%  content_shell  content_shell          [.] WTF::StringImpl::hashSlowCase() const
After:  0.37%  content_shell  content_shell          [.] WTF::StringImpl::hashSlowCase() const

There are likely other savings as well, but the effect on StringImpl::hashSlowCase
is the most dramatic change to the profile.

[Alexey Proskuryakov]

FWIW, I don't understand this change. StringBuilder only builds the string once already, and presumably does that in an optimal manner.

And what does XHR response have to do with StringImpl::hashSlowCase()? Who would ever want to calculate its hash?

[Geoffrey Garen]

I think Ben recently changed our DOM bindings to share JSStrings based on character content -- so, as the XHR is changing as new data arrives over the network, each new access from JavaScript will hash the characters in the XHR.

[Geoffrey Garen]

Perhaps this is a reason to change back to hashing based on pointer identity.