Large substrings ~9000x faster in Firefox than Chrome: why?

Question

The Benchmark: http://jsperf.com/substringing

So, I\'m starting up my very first HTML5 browser-based client-side project. It\'s going to have to parse very, very large

Answer 1

Have you eliminated the reading of .length from your benchmark results?

I believe V8 has a few representations of a string:

1. a sequence of ASCII bytes
2. a sequence of UTF-16 code units.
3. a slice of a string (result of substring)
4. a concatenation of two strings.

Number 4 is what makes string += efficient.

I'm just guessing but if they're trying to pack two string pointers and a length into a small space, they may not be able to cache large lengths with the pointers, so may end up walking the joined link list in order to compute the length. This assumes of course that Array.prototype.join creates strings of form (4) from the array parts.

It does lead to a testable hypothesis which would explain the discrepancy even absent buffer copies.

EDIT:

I looked through the V8 source code and StringBuilderConcat is where I would start pulling, especially runtime.cc.