Home/ Questions/Q 5970613
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T20:24:01+00:00

The Benchmark: http://jsperf.com/substringing So, I’m starting up my very first HTML5 browser-based client-side project.

  • 0

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 text files into, essentially, an array or arrays of objects. I know how I’m going to go about coding it; my primary concern right now is getting the parser code as fast as I can get it, and my primary testbed is Chrome. However, while looking at the differences between substring methods (I haven’t touched JavaScript in a long, long time), I noticed that this benchmark was incredibly slow in Chrome compared to FireFox. Why?

My first assumption is that it has to do with the way FireFox’s JS engine would handle string objects, and that for FireFox this operation is simple pointer manipulation, while for Chrome it’s actually doing hard copies. But, I’m not sure why Chrome wouldn’t do pointer manipulation or why FireFox would. Anyone have some insight?

JSPerf appears to be throwing out my FireFox results, not displaying them on the BrowserScope. For me, I’m getting 9,568,203 ±1.44% Ops/sec on .substr() in FF4.

Edit: So I see a FF3.5 performance result down there actually below Chrome. So I decided to test my pointers hypothesis. This brought me to a 2nd revision of my Substrings test, which is doing 1,092,718±1.62% Ops/sec in FF4 versus 1,195±3.81% Ops/sec in Chrome, down to only 1000x faster, but still an inexplicable difference in performance.

A postscriptum: No, I’m not concerned one lick about Internet Explorer. I’m concerned about trying to improve my skills and getting to know this language on a deeper level.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In the case of Spidermonkey (the JS engine in Firefox), a substring() call just creates a new “dependent string”: a string object that stores a pointer to the thing it’s a substring off and the start and end offsets. This is precisely to make substring() fast, and is an obvious optimization given immutable strings.

    As for why V8 does not do that… A possibility is that V8 is trying to save space: in the dependent string setup if you hold on to the substring but forget the original string, the original string can’t get GCed because the substring is using part of its string data.

    In any case, I just looked at the V8 source, ans it looks like they just don’t do any sort of dependent strings at all; the comments don’t explain why they don’t, though.

    [Update, 12/2013]: A few months after I gave the above answer V8 added support for dependent strings, as Paul Draper points out.

    • 0