Bug 117781
| Summary: | Consider using String rope for XMLHttpRequest.responseText | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Ryosuke Niwa <rniwa> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ap, barraclough, benjamin, ggaren |
| Priority: | P2 | Keywords: | BlinkMergeCandidate |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
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.