An XMLHttpRequest's responseText attribute used to be stored in a ScriptString, which internally stored the response string as a sequence of UTF-16 StringImpl's appended into a V8 string using V8::String::Concat(). This meant that the typical use case where the .responseText is built up by a sequence of append() calls we never had to copy the buffer, we just passed in a series of UTF-16 segments to V8 and let it manage the set. After 69668, .responseText is built using the StringBuilder class which appends into a flat buffer and copies when necessary (looks like it uses a 2x growth factor currently). This regresses performance and memory in a few ways that we should address. This is also a good opportunity to examine other strategies for how to manage .responseText such as keeping raw bytes around and lazily decoding to UTF-16. See https://bugs.webkit.org/show_bug.cgi?id=29909 for the initial implementation of V8's ScriptString.
We (gbarra and I) chatted about this some in IRC. The conclusion is that the best thing to do for now is probably to #ifdef a V8 implementation in XMLHttpRequest that has the useful properties. According to Dave Levin this has implications for the inspector as well since it has the ability to log XHR response bodies. We'll want to be careful that the inspector is referencing an efficient representation of the string and not accidentally flattening a buffer all the time or something else silly.