{"id":576,"date":"2009-11-04T21:08:53","date_gmt":"2009-11-05T01:08:53","guid":{"rendered":"http:\/\/www.outofwhatbox.com\/blog\/?p=576"},"modified":"2009-11-07T10:49:09","modified_gmt":"2009-11-07T14:49:09","slug":"trimming-trim-via-razing-arrays-javascript","status":"publish","type":"post","link":"https:\/\/www.outofwhatbox.com\/blog\/2009\/11\/trimming-trim-via-razing-arrays-javascript\/","title":{"rendered":"Trimming trim via razing arrays (JavaScript)"},"content":{"rendered":"

Back in 2007, Steve Levithan compared the speed<\/a> of different implementations for the missing JavaScript String.trim()<\/code> function. Steve’s blog post has launched The Comment Thread That Will Not Die, as a number of folks have been tempted to try their hand at writing their own implementation.<\/p>\n

Count me in.<\/p>\n

It started when Yesudeep Mangalapilly’s version<\/a> caught my attention. Yesudeep, working with an idea from Michael Lee Finney<\/a>, had a fast implementation that didn’t use regular expressions. Instead of regexps, Yesudeep’s and Michael’s versions scan the string one character at a time, from the front and back ends, checking each character against a lookup table to determine if it’s whitespace.<\/p>\n

However: The largest Unicode code point that’s counted as whitespace is U+3000 (pdf)<\/em><\/a> (12288 in decimal), the Ideographic Space<\/a> character. Hence, the lookup table array in Michael’s and Yasudeep’s implementations has a length of 12289, with most entries undefined. That’s a pretty large array, and a pretty sparse one.<\/p>\n

Even though these were already among the fastest of the trim<\/code>s, I wondered if using a large array as a lookup table might carry any performance penalty. My concern stemmed from the fact that JavaScript arrays grow dynamically<\/a>, adjusting in size to hold the highest index assigned into them. This poses a challenge to the interpreter: If it always places an array in a linear block of memory (as in C++), then accommodating array growth is likely to be a problem. So, to allow for reasonable performance at the array grows, the interpreter might not use a linear storage model for arrays. Non-linear models (trees or linked lists, for example) may make random access to the array slower, but would allow for reasonable performance when growing the array, while exhibiting reasonable memory consumption1<\/a><\/sup>.<\/p>\n

Through testing in three popular browsers, I found reason to be concerned about large arrays. I profiled the trim17<\/code> method (Yasudeep’s implementation), using input strings that contained only spaces and tabs for whitespace. After this profiling run, I trimmed trim17<\/code>‘s lookup table<\/a>\u00e2\u20ac\u201dhacked it, really\u00e2\u20ac\u201dby removing all entries above U+0020, and so limiting it to recognizing only ASCII whitespace chars. Then I profiled it again. <\/p>\n

The table below shows the milliseconds spent within the two versions of trim17<\/code>; the difference between their runtimes is most likely due to the change in size of the lookup table array.<\/p>\n\n\n\n\n\n\n
<\/th>\nOriginal trim17<\/code><\/strong><\/th>\nReduced trim17<\/code><\/strong><\/th>\n% Saved<\/strong><\/th>\n<\/tr>\n
Internet Explorer 8<\/strong><\/td>\n\n

27,328<\/p>\n<\/td>\n

\n

20,281<\/p>\n<\/td>\n

\n

26<\/p>\n<\/td>\n<\/tr>\n

Firefox 3.5<\/strong><\/td>\n\n

3,689<\/p>\n<\/td>\n

\n

2,978<\/p>\n<\/td>\n

\n

20<\/p>\n<\/td>\n<\/tr>\n

Chrome 3.0<\/strong><\/td>\n\n

610<\/p>\n<\/td>\n

\n

191<\/p>\n<\/td>\n

\n

69<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These results confirm that, in JavaScript, accessing larger arrays can be slower than accessing smaller arrays.<\/p>\n

\n

But, perhaps applying these results to all arrays is an overgeneralization. Ideally, at least, it should be possible for an interpreter to recognize a “read-only” array, and use a more efficient layout for it. That is, if the interpreter can verify that an array isn’t modified after its initial construction, then perhaps it can safely flatten out the array into a linear block of memory.<\/p>\n

The array in trim17<\/code> was constructed as a property of the String<\/code> prototype. An array couldn’t be more modifiable than that, and so I wouldn’t expect it to be flattened by the interpreter. But suppose the array were accessible only from within a single function (a closure<\/a>). In that case, if that single function isn’t modifying the array, we know that nothing will. Depending on the JavaScript interpreter, that might allow for better performance.<\/p>\n

I changed the code accordingly, but the actual improvement in speed was… unremarkable. Nonexistent, even. It may have eked out around a 5% gain in some tests, but there’s enough noise in the measurements that it’s hard to be sure. Still, I dislike globals (and, especially, modifiable globals), so I decided to stick with the closure. (Besides, maybe someday, somewhere, an optimizing interpreter will know how to make use of it.)<\/p>\n

The next approach was to try using a smaller array. Or, rather, two smaller arrays: One to represent the whitespace characters at and below U+0020, and another to represent the whitespace characters between U+2000 and U+205f. To keep the second array small, its indices are offset by \u00e2\u20ac\u201c0x2000<\/code>; this gives it a size of 0x0060<\/code> (96 decimal) entries. (There are three whitespace values that aren’t in either array: U+1680, U+180e, and U+3000. The new code checks for these explicitly.)<\/p>\n

Even with smaller arrays, I found that random access into them is still slower than making a few comparisons on scalar variables. Hence the code is written so that, for any character value, it consults no more than one of the two lookup tables, and then only if the character is in a reasonable range for that table.<\/p>\n

Here’s the new method:<\/p>\n

\r\nvar trimOOWB = (function() {\r\n\r\n var whiteSpace = new Array(0x00a0 + 1);\r\n whiteSpace[0x0009] = true;    whiteSpace[0x000a] = true;\r\n whiteSpace[0x000b] = true;    whiteSpace[0x000c] = true;\r\n whiteSpace[0x000d] = true;    whiteSpace[0x0020] = true;\r\n whiteSpace[0x0085] = true;    whiteSpace[0x00a0] = true;\r\n\r\n var whiteSpace2 = new Array(0x005f + 1);\r\n var base = 0x2000;\r\n whiteSpace2[0x2000 - base] = true;  whiteSpace2[0x2001 - base] = true;\r\n whiteSpace2[0x2002 - base] = true;  whiteSpace2[0x2003 - base] = true;\r\n whiteSpace2[0x2004 - base] = true;  whiteSpace2[0x2005 - base] = true;\r\n whiteSpace2[0x2006 - base] = true;  whiteSpace2[0x2007 - base] = true;\r\n whiteSpace2[0x2008 - base] = true;  whiteSpace2[0x2009 - base] = true;\r\n whiteSpace2[0x200a - base] = true;  whiteSpace2[0x200b - base] = true;\r\n whiteSpace2[0x2028 - base] = true;  whiteSpace2[0x2029 - base] = true;\r\n whiteSpace2[0x202f - base] = true;  whiteSpace2[0x205f - base] = true;\r\n\r\n\r\n    function trimOOWB2(str) {\r\n        var ws = whiteSpace, ws2 = whiteSpace2;\r\n        var i=0, len=str.length, ch;\r\n        while ((ch = str.charCodeAt(--len)) &amp;&amp;\r\n               (ch &lt;= 0x00A0 ? ws[ch] :\r\n                (ch &gt;= 0x2000 ? (ch===0x3000 || ws2[ch - 0x2000])\r\n                 : (ch===0x1680 || ch===0x180e ))))\r\n            ;\r\n        \r\n        if (++len) {\r\n            while ((ch = str.charCodeAt(i)) &amp;&amp;\r\n                   (ch &lt;= 0x00A0 ? ws[ch] :\r\n                    (ch &gt;= 0x2000 ? (ch===0x3000 || ws2[ch - 0x2000])\r\n                     : (ch===0x1680 || ch===0x180e )))) {\r\n                ++i; \r\n            }\r\n        }\r\n        return str.substring(i, len);\r\n    }\r\n\r\n    return trimOOWB2;\r\n})();\r\n<\/pre>\n
I benchmarked the new function (trimOOWB<\/code>) and Yesudeep’s trim17<\/code> function, using two sets of input strings. In the first test, only legacy ASCII whitespace characters (e.g., spaces and tabs) were used, as in the test above. The second test data set used the full set of whitespace in the Unicode character set. The numbers shown are milliseconds spent within the trim functions; lower is better.<\/p>\n\n\n\n\n\n\n
<\/th>\ntrim17 (ASCII)<\/code><\/strong><\/th>\ntrimOOWB (ASCII)<\/code><\/strong><\/th>\n% saved<\/code><\/strong><\/th>\ntrim17 (Unicode)<\/code><\/strong><\/th>\ntrimOOWB (Unicode)<\/code><\/strong><\/th>\n% saved<\/code><\/strong><\/th>\n<\/tr>\n
Internet Explorer 8<\/strong><\/td>\n25,953<\/td>\n22,359<\/td>\n14<\/td>\n27,469<\/td>\n26,500<\/td>\n4<\/td>\n<\/tr>\n
Firefox 3.5<\/strong><\/td>\n3,706<\/td>\n3,089<\/td>\n17<\/td>\n3,831<\/td>\n3,439<\/td>\n10<\/td>\n<\/tr>\n
Google Chrome 3.0<\/strong><\/td>\n604<\/td>\n139<\/td>\n77<\/td>\n664<\/td>\n166<\/td>\n75<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
A final thought<\/h3>\n
It’s interesting that there’s a direct correlation between the base time for the browser to execute trim17<\/code>, and the percentage of time saved by trimOOWB<\/code>. In other words, the percentage<\/em> of performance boost from using smaller arrays increases as the browser’s speed increases: IE showed the highest time and lowest gain, followed by Firefox on both counts, and finishing with Chrome, which had the lowest base time and the highest percentage gain.<\/p>\n
I’m guessing here, but I think the easiest way to explain this is that all three JavaScript interpreters are using roughly equivalent strategies for managing arrays. The percentages gained are different because the same absolute<\/em> time savings in Chrome results in a higher relative<\/em> performance boost when compared to IE or Firefox.<\/p>\n
That raises a question, though: Is it possible that the structure of trimOOWB<\/code> gives it any performance advantage over trim17<\/code> aside from<\/em> the savings generated through reducing the array size? I’ve looked for such artifacts in the tests. In short, and skipping the details for now, I think it’s likely that such artifacts couldn’t account for more than one quarter of the overall speed boost; it’s probably much less than that. It’s at least as likely that the overhead added by trimOOWB<\/code> is obscuring<\/em> part of the overall performance boost.<\/p>\n
Another final thought<\/h3>\n
The multiple comparisons made in trimOOWB<\/code> might raise the question: Why not try using a switch<\/code> statement instead of all those conditionals? Well, I did<\/em> try this, with mixed results. On one hand, Firefox showed a significant speedup, around 25%. On the other hand, IE may have been a little slower, and Chrome was more than twice as slow. (Besides, it was a switch<\/code> statement. We’re looking for speed, but a fellow’s got to have some<\/em> standards.)<\/p>\n
A final final thought<\/h3>\n
Using a closure offers another advantage: It’s simple to redirect calls to trim<\/code> to the native String.trim() function, if the browser supports it. All that’s required is to change the return<\/code> in the outer (anonymous) function from this:<\/p>\n
\r\n    return trimOOWB2;\r\n<\/pre>\n
to:<\/p>\n
\r\n    return String.trim || trimOOWB2;\r\n<\/pre>\n
ECMAScript 5.0 is slated<\/a> to include String.trim<\/code>, so it’s probably worth thinking ahead for this. In Firefox 3.5\u00e2\u20ac\u201dthe only current browser that I know of that supports String.trim<\/code>\u00e2\u20ac\u201dcalls to the native String.trim<\/code> run in a fraction of the time of any of the JavaScript implementations.<\/p>\n
Note<\/strong>: Firefox’s native implementation of String.trim<\/code> does not count U+1680 or U+180E as whitespace. It does treat U+3000 as whitespace.<\/div>\n
\n
1<\/a><\/sup>Yes, I wrote “JavaScript” and “reasonable memory consumption” in the same article. Go ahead and snicker.<\/div>\n
\n","protected":false},"excerpt":{"rendered":"
It may well be that for better JavaScript performance, large arrays should be avoided where possible. That seems fairly clear in this case, where an already fast implementation of the missing String.trim() method was made even faster by using much smaller lookup table arrays.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[26,3,20],"tags":[23,29,28],"_links":{"self":[{"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/posts\/576"}],"collection":[{"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/comments?post=576"}],"version-history":[{"count":6,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/posts\/576\/revisions"}],"predecessor-version":[{"id":582,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/posts\/576\/revisions\/582"}],"wp:attachment":[{"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/media?parent=576"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/categories?post=576"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.outofwhatbox.com\/blog\/wp-json\/wp\/v2\/tags?post=576"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}