Out Of What Box?

SyntaxHighlighter: Easier to load; faster to boot?

Dan Breslau — Mon, 08 Feb 2010 00:45:14 +0000

SyntaxHighlighter has a relatively high surface area, typically requiring two CSS files and at least two JavaScript files to be linked into a web page. Here’s a truncated example:



	


...



...Some kind of interesting page content usually goes here,
but we're not interested in that right now...

Some users have wanted a simpler way to integrate SyntaxHighlighter into their sites. Last year, David Chambers wrote a script that uses the Prototype library to load the required CSS and brush files. He ran into a troubling quirk in SyntaxHighlighter: It needs any required brush files to be loaded before it starts highlighting. I responded by updating the OOWB fork of SyntaxHighlighter, so that brushes could be loaded asynchronously. But that’s as far as I’d gone towards automated loading, until now.

I recently looked into adding automated loading to SyntaxHighlighter itself, coming up with not one, but two automated solutions. I should really say one and a half, as one is still in the alpha stage and will likely stay there.

The “alpha-stage” approach comprises a new JavaScript file that loads SyntaxHighlighter and the necessary brush files through AJAX, by way of a pair of simple Java servlets. I’d hoped that this would lead to faster load times, by reducing the total number of downloads. And so it does—sometimes. For testing, I used Google App Engine as the servlet host (using the free quotas.) Performance was inconsistent, to say the least; this is probably due to the Google App Engine’s method of starting up and shutting down servlets. It seemed that only by making repeated hits on the servlets in rapid succession could I be sure of getting to a container that already had my servlets running, thus getting good load times.¹ The servlets are still up there; if you’d like the Java source (to host them elsewhere), and/or the JavaScript for using them, just let me know.

I also implemented a pure JavaScript approach, which I hadn’t expected to yield better load times. Yet I’ve seen a number of cases where this is faster than the original, static way of loading SyntaxHighlighter. I’m releasing a new download so that you can try it out. I highly recommend that you test it thoroughly before putting it into real use.

To use this new method, the web page invokes SyntaxHighlighter.boot instead of SyntaxHighlighter.all. When boot is used as the entry point, SyntaxHighlighter determines which brushes are required by the web page, and issues HTTP requests for each brush file (as well as the appropriate CSS.) These requests use the age-old method of adding a tag for each brush, and a tag for each CSS file.

Using SyntaxHighlighter.boot, a web page only needs to add a couple of scripts, usually at the end of the . No CSS link elements are required.

That’s it. Every page on your site can use the same set-up, regardless of which brush files it needs. (For another example, look at the HTML source for this page.)

When an HTML page includes external scripts—that is, elements with src attributes, the browser loads the script files synchronously, as it encounters them in the HTML. When the scripts are loaded dynamically, the browser can load them asynchronously; several scripts may then be loading simultaneously. This can be particularly helpful for pages that use multiple brushes. Here’s a Firebug sequence diagram of a web page with five brushes, loading in SyntaxHighlighter’s traditional way:

(Click on image for larger view)

Here’s the same page, modified to use the boot method. Notice that, unlike in the first picture, the shBrush...js files are loaded in parallel:

(Click on image for larger view)

Of course, this isn’t an entirely new discovery, but it came as a pleasant surprise nonetheless.

Availability

In addition to SyntaxHighlighter itself, I also modified Viper007Bond’s SyntaxHighlighter Evolved plugin for WordPress to use the new boot method. This simplified the code quite a bit, though it may have introduced bugs.

SyntaxHighlighter and SyntaxHighlighter Evolved are each available on the downloads page. Test before using. Note: If you’ve been using SyntaxHighlighter Evolved, you will probably need to re-set your settings if you install this plugin.

Implementation notes

In the traditional SyntaxHighlighter, all brushes must be loaded before SyntaxHighlighter.all is invoked. In this fork, “>brushes can load at any time after shCore.js has been loaded. This flexibility was key to the design of the boot method: If a brush is loaded after SyntaxHighlighter.all or SyntaxHighlighter.boot is invoked, SyntaxHighlighter looks through the page to see if there’s any input requesting the newly loaded brush.

The boot method needs to map each brush name to the script file that implements that brush. I implemented this by modifying the Perl script that builds and stages SyntaxHighlighter. The script now parses the *Brush.js files in the source tree, pulling out the names and aliases supported by each file, and writes them into an array in shCore.js. The downside of this is that testing via the boot method requires re-running the script, which builds and stages the files into a new directory, from where I can run tests. Even though the script only takes about a second, it’s crossed the boundary between having no build step in the development cycle, and having any build step in the development cycle.

When You Come To A Fork In The Road, Take It.

I had two motives for working on SyntaxHighlighter: One, to improve its display of code on my own blog and elsewhere. Two, as a training ground for learning JavaScript.

I was between jobs when I took on this project. As of this Monday, that will no longer be the case. That’s great news for me, but much as I’d like to keep the SyntaxHighlighter work moving forward, I don’t really know if or when I’ll have the time for it. On the other hand, I no longer feel like I need a private JavaScript training ground. So, I’ve pushed my repository to bitbucket.org as a fork of Alex’s repository. If he so chooses (and so far he hasn’t, which is fine), Alex is welcome to merge the fork into his branch. Perhaps more importantly, anyone else can now fork the code, and/or make contributions to this fork.

I do have some more goals in mind for SyntaxHighlighter. I’ll be writing about them in the not-too-distant future.

¹Perhaps a faster host would lead to the faster load times I’d hoped for; but that would probably require payment, which makes this approach considerably less attractive.

Update of Forked SyntaxHighlighter

Dan Breslau — Fri, 18 Dec 2009 17:20:19 +0000

As promised, I’ve updated this site’s fork of the SyntaxHighlighter software by Alex Gorbatchev. I’ve merged in many of the changes that Alex included in his 2.1.364 release, but with the following differences:

In 2.1.364, the ruler functionality was removed. It’s still included here.
2.1.364 changed the way that wrapped lines are presented. I’ve kept the old presentation, but modified the icon that’s used to signify wrapping.
Internally, 2.1.364 uses a separate HTML table to represent each line of source. I’ve maintained the older pattern of simply using a separate
to represent each line.

Other new bits in this release:

I’ve added a “Hide” button to the toolbar. Code blocks can now be expanded/collapsed at the user’s whim. (As before, an author can still choose to present a block in the hidden/collapsed state.)
When both a horizontal scrollbar and a gutter (the line number column) are displayed, the scrollbar no longer extends under the gutter. (I think this is an improvement; as always, feedback is welcome.) Update: I’ve backed out this change; it was causing problems with IE7.

The ZIP file is available through the Download Page.

Do not adjust your eyes; it’s just a new theme.

Dan Breslau — Thu, 17 Dec 2009 05:43:33 +0000

I’ve just gone live with a different WordPress theme. So, if you’re feeling a bit lost, don’t panic. This is a new theme, iTech, which was just released last month. I’ve tailored the CSS, fixed a bug or two in the php, and even managed to add a new customization option. It’s been a good learning experience. Most importantly, I hope you’ll like the new look. Let me know what you think.

New version of SyntaxHighlighter coming

Some folks have asked me offline if I’m going to be merging Alex Gorbatchev’s 2.1.364 version of SyntaxHighlighter with the OOWB fork that I’ve been supporting here. The answer to that is yes; if all goes well, I should be posting it in the next few days. As for creating a public repository, perhaps on bitbucket: Maybe. If you’d like to see this happen, please let me know. Actually, I’d like to hear from anyone who’s rolled out the OOWB fork: What site(s) are you using it on, and how is it working out? Please leave a comment, or send email.

Did I say “fork”? Uh, yeah. While 2.1.364 is solid, it doesn’t cover most of the improvements that I’ve made (check the Download Page to see a summary.) Ultimately, I’d like to see these changes rolled back into Alex’s version, but that doesn’t appear to be happening anytime soon. There could be good reasons for that; certainly my version looks larger, just for starters. (I think that the total footprint may be smaller, but that’s a tough call.) All I can really say is that we’ll see how it goes. I plan to keep making improvements in the software, at least for my own sake; but I regard Alex as the primary author and will continue to do so.

JavaScript Array Performance, And Why It Matters

Dan Breslau — Tue, 01 Dec 2009 15:21:13 +0000

My last post described how a JavaScript array had become a performance bottleneck. Here, I’ll delve further into how some JavaScript programs become array-bound, and how to break that bind when you need to.

Let’s start with this:

As the graph shows, JavaScript array performance ranges from OK (nearly equivalent to scalars) to awful. The reasons for poor performance vary, but most can be boiled down to this: The JavaScript interpreter is essentially left guessing about how an array will be used. And guess it does. When an array is constructed and initialized, the interpreter can observe where data is stored into a new array. Certain kinds of patterns may nudge it to optimize for better speed, or lower memory consumption. So, performance suffers when the interpreter makes the wrong interpretation.

I looked into performance of JavaScript arrays with three popular Windows browsers: Internet Explorer 8, Google Chrome 3.0, and Firefox 3.5. Broadly speaking, these all seem to look for two or three types of arrays:

Dense arrays: These provide faster access to individual elements of the array.
Sparse arrays: These are typically optimized for lower memory use.
Sized arrays: A variant of sparse arrays that are optimized for speed for certain cases.

The interpreters optimize for dense arrays if the array’s elements are initialized in a continuous range, starting at index 0. This initialization can be done before there’s any data for the array, by using placeholders such as 0, null, or even undefined. (There are other ways to get this optimization; this is simply the most reliable approach.)

Passing the array’s size in the constructor may also bring better performance. In my testing, I saw this only with sparse arrays in IE8 and (perhaps) in Chrome. I’ll refer to these as sized arrays; see below for some additional notes.

If an array is created as neither a dense nor a sized array, it’s treated as a sparse array.

As a general rule, the array’s behavior is established shortly after construction. If you sparsely populate an array, then assign other values to the remaining elements, you’re left with a densely-populated sparse array.¹

Hold it there. A densely populated sparse array? Holy leaky abstractions, Batman!

Perhaps we’re lacking some terms. If we’re trying to coax better performance from a sparse array by filling it up with placeholder values, that doesn’t make it a dense array—not from your program’s perspective, at least. To describe it from the interpreter’s perspective, I’ll refer to an array that’s initialized after creation—with live or dead data—as a cleared array. An uninitialized array that is populated at random indices is a default array, regardless of how dense it eventually becomes. Finally, a sized array is, well, a sized array. So, that “densely populated sparse array” is now a “densely populated default array.” That’s still an awkward phrase, but at least it’s not an oxymoron.

Now that we can finally get to some data, let’s discuss scalability. This graph represents the time taken to read about 30,000,000 values from arrays of various sizes, using three Windows browsers. Seven data sets are presented: Cleared and default arrays for each of IE8, Google Chrome 3.0, and Firefox 3.5, plus sized arrays for IE8.

Array Size Vs. Access Time. (Click for larger graph with legend)

Note that in three of the seven cases, time grows linearly as size increases². This growth effectively multiplies the program’s complexity by O(N). That is, an algorithm that might normally have O(N) performance instead shows O(N²) performance, and so on. This can have a sizable impact on scalability.

The graph makes it clear that the fastest arrays are cleared. However, making a very sparse cleared array would gobble up a large swath of memory for a small number of values. For such cases, you may want to stick with sparse or sized arrays. Here’s a closer look at their performance.

The following tests all used arrays of 180,000 elements. Each data point represents performance with a different “hit ratio”; that is, the ratio of defined values read from the array. While array density also varied, its effect appears in only one case, which I’ll show separately³. For reference, these graphs also show the performance with cleared arrays.

This graph shows the performance of sized, default, and cleared arrays in IE8. Notice that the “sized” trendline (in blue) begins significantly above the “default” trendline, and ends slightly above the “cleared” trendline. Clearly, IE optimizes sized arrays to work better when reading defined values.

Array Hits Vs. Access Time in IE8. (Click for larger graph with legend)

Firefox 3.5 also looks slower when accessing undefined elements, but there’s no real gain from passing a size parameter to the array constructor:

Array Hits Vs. Access Time in Firefox 3.5. (Click for larger graph with legend)

In Chrome, array access times are clustered into high and low ranges of values, based on array density. Chrome performs markedly better with arrays having a density of 10% or higher, vs. arrays of lower density. The data sets below have been split accordingly. Since there’s much more variation between these two ranges than here is among them, it’s a good bet that the 10% threshold is hard-coded somewhere in Chrome’s V8 JavaScript interpreter.

Array Hits Vs. Access Time in Chrome, by array density. (Click for larger graph with legend)

Notes on sized arrays

It makes sense that if a size is passed to the array constructor, and the size value is accurate, then the interpreter can optimize the array for that size. The problem is that the size value won’t always be accurate; nor does it suggest how dense the array might become. Hence the interpreter may not be able to rely on the size value even when it’s present.

Sized array behavior in IE8 isn’t what I’d expected. I’d found a note written prior to IE8’s release by one of its developers, which I had taken to mean that these arrays should perform like cleared arrays, but that’s clearly not the case. Sized arrays in IE8 actually incur a small penalty when accessing undefined array elements, to the point where if you access only undefined elements, a sized array may be slower than a default array. On a closer reading, the note refers to “any indexed entry” within the array’s range [emphasis mine.] Of course, undefined entries wouldn’t be indexed. The note was accurate, but arguably didn’t go far enough.

In Chrome, using an explicit size for a sparse array does seem to make a small but measurable difference in some cases. But on the whole, there’s little reason to use this for improved performance, especially since Chrome is currently the browser least in need of a performance boost in these tests.

The performance of Firefox 3.5 suggests that it ignores the constructor’s size parameter. However, a quick trip through the browser’s source code indicates that the size should make a difference. Perhaps other kinds of tests would be able to draw this out, or perhaps there’s an opportunity for improvement in the code.

Memory Consumption

Measuring the physical size of JavaScript data is a sketchy undertaking. About the best one can do is to compare the virtual memory size of the browser process before and after creating a large array. This isn’t going to be very accurate. All the same, where there’s a large difference between values, it’s probably significant.

`Browser`	`Size Estimate, Default / Sized Arrays (Bytes)`	`Size Estimate, Cleared Arrays (Bytes)`
Internet Explorer 8	(# of values) x (approximately 76)	(Length of array) x (approx. 46)
Firefox 3.5	(# of values) x (approx. 63)	(Length of array) x (approx. 5)
Google Chrome 3.0	(Length of array) x (30–70)	(Length of array) x (approx. 14)

In my last post, I wrote that a sparse 12K array of integers, implemented as a hash table, would likely consume over 36K of memory. If these measurements are reasonable, that was a gross understatement; a sparse 12K array could actually consume more than 70 bytes per element, or upwards of 860K.

At the extremes, for two arrays with the same length, one that’s very dense may use less memory than one of lower density—even though the lower density array, by definition, contains fewer values. Chrome and Firefox seem to account for this internally as they organize the array structure, but I’m not sure whether IE8 does.

Recommendations

Remember that premature optimization is folly, and all optimization has its costs. If you use the hints that I’ve described, keep in mind that the interpreter isn’t obliged to obey your intentions. Consider creating a factory method for arrays, so that if as the rules change, you can most easily adapt your code to suit.

Use cleared arrays if speed is critical, or if the array reaches around 50% density. But don’t use them habitually, especially not for sparse arrays.
Because of IE8’s quirks, you should think twice before creating sized arrays. They’re helpful only if you have sparse data and you won’t often access an undefined array element.

Looking ahead

JavaScript’s arrays are pleasant enough in normal use; but like all abstractions, they have their leaks. As JavaScript is used for increasingly sophisticated applications, it might be worthwhile for its designers to take a fresh look at scalability. There are ways to get the desired results, but negotiation via secret handshake doesn’t scale terribly well.

Without marring JavaScript’s simplicity, it should be possible to extend the language so that, when necessary, the developer can make plain to the interpreter what it should expect for a particular array. For example, this could mean adding APIs or syntax that let the developer declare the array’s expected size, density, and so forth. Or the problem could be addressed from the other direction: Simply allow the developer to request a structure that favors higher speed, or more compactness, for a particular array.

And although read-only objects may be a special case, I started down this path by looking at an array used as a lookup table which is effectively read-only after initialization. It would be nice if I could let the interpreter know this. A version of Ruby’s freeze method would fit the bill. This would give the interpreter a hint to optimize the array for read-only access, though it wouldn’t be required to do so.

Dreaming further, I’m also holding out hope that closures can be better optimized. After initialization, the lookup table in my version of String.trim() was only accessible to a single, read-only method. If the interpreter can verify that nothing’s going to change the array, it could move it to faster storage. Yes, this brings us back around to secret handshakes. But since closures have their own merits, I see this more as the icing on the cake.

¹ Making a fresh copy using slice(0) should get you better performance. (Well, it’s worked for me, but I make no promises.)

² There are really four cases, but the fourth one (cleared arrays in IE8) shows very slow growth in runtime. Also note that the numbers suggest that Chrome’s performance improves slightly as array size increases. This may be an artifact of the benchmark.

³ Density and hit ratio can be covariant, but here they aren’t. That is, these tests were designed so that, as long as the density was under 100%, the hit ratio could vary independently.

JavaScript Array Performance: Initialize to Optimize

Dan Breslau — Tue, 17 Nov 2009 16:39:22 +0000

After delving into the issue of JavaScript array performance, I came upon a pair of blog entries on MSDN addressing the topic. These posts describe situations where the then-forthcoming IE8 could provide more performant arrays. The blog also partially confirms, and partially refutes, my thoughts on how JavaScript interpreters handle arrays. The blog’s focus, of course, is the JScript engine in IE, but the advice that it offers seems to work well with other major browsers.

The blog confirms that IE’s JavaScript interpreter manages arrays using a nonlinear structure, essentially a hash table. I’d guessed at this after seeing lower performance in trimOOWB when its lookup table was implemented as a large, and sparse, array. But contrary to my guess, this isn’t about avoiding re-allocation bottlenecks. It’s for dealing with sparse arrays without consuming unreasonable amounts of memory¹. (I’m feeling a little sheepish about this: Even though I’d noted the sparseness of the lookup table, I hadn’t made the connection. In fact, I’d been somewhat dismissive of that possibility. Live and learn.)

The blog also says that as of IE8, the JScript engine has heuristics for determining if an array is “dense”. It implements a dense array with a linear, array-like index in addition to its standard hash-like data structure; this index can make random access into the array much faster. The blog indicates that IE8 considers an array to be dense if either of the following conditions is true:

You construct the array with an explicit size, and you don’t grow the array past that initial size.
After creating the array, you initialize a continuous range of indices, starting from 0, up to and including the highest index that you expect to use. You must do this before writing into random indices within the array.²

As the writer says, using either of these two techniques should ensure that the array heuristics in IE 8 will treat your array as a dense array. The interpreter is free to decide to treat other arrays as dense, too. However, the testing I’ve done suggests that it’s not quite as simple as this. Contrary to the blog’s guidelines, I found that:

Creating the array with an explicit size (whether or not followed by initializing the elements) had no measurable impact on the speed of the trim method.
Initializing the lookup table’s full range of 12,289 elements (the vast majority of which are not whitespace) did improve performance.

This finding is specific to the trim method, and so these results should not be used as general performance guidelines. The usage pattern for a particular array can greatly affect its performance profile. I’ve found unrelated cases where specifying the array’s size could help or hurt performance. (I’ll write more about this in my next post.)

Following up on these hints led to a new version of trim that’s simpler and faster than my previous effort. This version is actually more closely related to the trim17 method from Yesudeep Mangalapilly than it is to trimOOWB. Hence I’ve named this newer one trim18 to reaffirm its heritage. (In Steve Levithan’s original post on JavaScript trim methods, he assigned numbers to each of the trim implementations that he examined. Yesudeep took up that naming scheme, and now I’m doing so as well.)

An Intermediary Thought

Remember that premature optimization is folly, and all optimization has its costs. In this case, we’re buying performance by fully initializing a 12K JavaScript array. If the interpreter stores this using a hash table as well as an array, then the table will likely consume over 36K of memory. Is the benefit worth the cost? It could be, especially if we’re not running on a cell phone. But please don’t take away from this that you should initialize every array that you create. That would ultimately be self-defeating: One of the worst things you can do for performance is to consume more memory than you really need.

Performance

Since the last post, I’ve revised the benchmark for better precision. The structure is the same—both benchmarks call the three trim methods repeatedly with a fixed set of input data—but in the newer benchmark, the input strings are much longer, and the number of iterations is lower. This should yield more precise measurements of execution time. All the same, these results should be used with care; as is often said in the U.S.A, your mileage will vary.

The benchmark results are shown below. Please remember that these tables are not directly comparable to the numbers in my previous post.

ASCII data (only spaces and tabs used for whitespace)

	`trim17`	`trimOOWB`	`% saved vs. trim17`	`trim18`	`% saved vs. trim17`
Internet Explorer 8	74,453	69,609	6.5	69,922	6.1
Firefox 3.5	6,776	3,732	44.9	3,003	55.7
Google Chrome 3.0	2,530	824	67.4	754	70.2

Unicode data (using all ASCII and Unicode whitespace characters)

	`trim17`	`trimOOWB`	`% saved vs. trim17`	`trim18`	`% saved vs. trim17`
Internet Explorer 8	76,188	74,468	2.3	72,484	4.9
Firefox 3.5	6,779	5,025	25.6	3,029	55.3
Google Chrome 3.0	2,780	940	66.2	810	70.9

trim18 implementation

I left the explicit size in the array constructor call, even though I’d found no benefit from using it. It seems unlikely to cause any harm, and there may be environments where this method’s performance might benefit from it.

var trim18 = (function() {

    var tableSize = 0x3000 + 1;
    var whiteSpace = new Array(tableSize);

    // Initialize the array elements before populating the data.
    // (This may help performance, by hinting to the interpreter that
    //  the array should not be managed as a sparse array.)

    for (var i = 0; i < tableSize; i++) {
        whiteSpace[i] = false;
    }

    whiteSpace[0x0009] = true;  whiteSpace[0x000a] = true;
    whiteSpace[0x000b] = true;  whiteSpace[0x000c] = true;
    whiteSpace[0x000d] = true;  whiteSpace[0x0020] = true;
    whiteSpace[0x0085] = true;  whiteSpace[0x00a0] = true;
    whiteSpace[0x1680] = true;  whiteSpace[0x180e] = true;
    whiteSpace[0x2000] = true;  whiteSpace[0x2001] = true;
    whiteSpace[0x2002] = true;  whiteSpace[0x2003] = true;
    whiteSpace[0x2004] = true;  whiteSpace[0x2005] = true;
    whiteSpace[0x2006] = true;  whiteSpace[0x2007] = true;
    whiteSpace[0x2008] = true;  whiteSpace[0x2009] = true;
    whiteSpace[0x200a] = true;  whiteSpace[0x200b] = true;
    whiteSpace[0x2028] = true;  whiteSpace[0x2029] = true;
    whiteSpace[0x202f] = true;  whiteSpace[0x205f] = true;
    whiteSpace[0x3000] = true;

    function trim18(str) {
        var len = str.length, ws = whiteSpace, i = 0;
        while (ws[str.charCodeAt(--len)]);
        if (++len){
            while (ws[str.charCodeAt(i)]){ ++i; }
        }
        return str.substring(i, len);
    }

    return trim18;
})();

¹ It’s also relevant that every JavaScript object needs a hash table to manage properties. Hence sparse arrays can be implemented easily by using this hash table for the same purpose. (Considering the design of JavaScript’s for...in loop statement, it looks as if the language designers intended this.)

² That is, you would need to initialize the array if you otherwise won’t be populating all of its elements, or if you won’t be populating them in strict order starting from 0. On the other hand, if your script would normally add data to the array starting from index 0 and working up from there, leaving no gaps, then you’re already squared away with IE8’s heuristics.

Trimming trim via razing arrays (JavaScript)

Dan Breslau — Thu, 05 Nov 2009 01:08:53 +0000

Back in 2007, Steve Levithan compared the speed of different implementations for the missing JavaScript String.trim() 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.

Count me in.

It started when Yesudeep Mangalapilly’s version caught my attention. Yesudeep, working with an idea from Michael Lee Finney, 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.

However: The largest Unicode code point that’s counted as whitespace is U+3000 (pdf) (12288 in decimal), the Ideographic Space 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.

Even though these were already among the fastest of the trims, 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, 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 consumption¹.

Through testing in three popular browsers, I found reason to be concerned about large arrays. I profiled the trim17 method (Yasudeep’s implementation), using input strings that contained only spaces and tabs for whitespace. After this profiling run, I trimmed trim17’s lookup table—hacked it, really—by removing all entries above U+0020, and so limiting it to recognizing only ASCII whitespace chars. Then I profiled it again.

The table below shows the milliseconds spent within the two versions of trim17; the difference between their runtimes is most likely due to the change in size of the lookup table array.

	Original `trim17`	Reduced `trim17`	% Saved
Internet Explorer 8	27,328	20,281	26
Firefox 3.5	3,689	2,978	20
Chrome 3.0	610	191	69

These results confirm that, in JavaScript, accessing larger arrays can be slower than accessing smaller arrays.

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.

The array in trim17 was constructed as a property of the String 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). 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.

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.)

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 –0x2000; this gives it a size of 0x0060 (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.)

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.

Here’s the new method:

var trimOOWB = (function() {

 var whiteSpace = new Array(0x00a0 + 1);
 whiteSpace[0x0009] = true;    whiteSpace[0x000a] = true;
 whiteSpace[0x000b] = true;    whiteSpace[0x000c] = true;
 whiteSpace[0x000d] = true;    whiteSpace[0x0020] = true;
 whiteSpace[0x0085] = true;    whiteSpace[0x00a0] = true;

 var whiteSpace2 = new Array(0x005f + 1);
 var base = 0x2000;
 whiteSpace2[0x2000 - base] = true;  whiteSpace2[0x2001 - base] = true;
 whiteSpace2[0x2002 - base] = true;  whiteSpace2[0x2003 - base] = true;
 whiteSpace2[0x2004 - base] = true;  whiteSpace2[0x2005 - base] = true;
 whiteSpace2[0x2006 - base] = true;  whiteSpace2[0x2007 - base] = true;
 whiteSpace2[0x2008 - base] = true;  whiteSpace2[0x2009 - base] = true;
 whiteSpace2[0x200a - base] = true;  whiteSpace2[0x200b - base] = true;
 whiteSpace2[0x2028 - base] = true;  whiteSpace2[0x2029 - base] = true;
 whiteSpace2[0x202f - base] = true;  whiteSpace2[0x205f - base] = true;

    function trimOOWB2(str) {
        var ws = whiteSpace, ws2 = whiteSpace2;
        var i=0, len=str.length, ch;
        while ((ch = str.charCodeAt(--len)) &&
               (ch <= 0x00A0 ? ws[ch] :
                (ch >= 0x2000 ? (ch===0x3000 || ws2[ch - 0x2000])
                 : (ch===0x1680 || ch===0x180e ))))
            ;

        if (++len) {
            while ((ch = str.charCodeAt(i)) &&
                   (ch <= 0x00A0 ? ws[ch] :
                    (ch >= 0x2000 ? (ch===0x3000 || ws2[ch - 0x2000])
                     : (ch===0x1680 || ch===0x180e )))) {
                ++i;
            }
        }
        return str.substring(i, len);
    }

    return trimOOWB2;
})();

I benchmarked the new function (trimOOWB) and Yesudeep’s trim17 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.

	`trim17 (ASCII)`	`trimOOWB (ASCII)`	`% saved`	`trim17 (Unicode)`	`trimOOWB (Unicode)`	`% saved`
Internet Explorer 8	25,953	22,359	14	27,469	26,500	4
Firefox 3.5	3,706	3,089	17	3,831	3,439	10
Google Chrome 3.0	604	139	77	664	166	75

A final thought

It’s interesting that there’s a direct correlation between the base time for the browser to execute trim17, and the percentage of time saved by trimOOWB. In other words, the percentage 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.

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 time savings in Chrome results in a higher relative performance boost when compared to IE or Firefox.

That raises a question, though: Is it possible that the structure of trimOOWB gives it any performance advantage over trim17 aside from 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 is obscuring part of the overall performance boost.

Another final thought

The multiple comparisons made in trimOOWB might raise the question: Why not try using a switch statement instead of all those conditionals? Well, I did 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 statement. We’re looking for speed, but a fellow’s got to have some standards.)

A final final thought

Using a closure offers another advantage: It’s simple to redirect calls to trim to the native String.trim() function, if the browser supports it. All that’s required is to change the return in the outer (anonymous) function from this:

    return trimOOWB2;

to:

    return String.trim || trimOOWB2;

ECMAScript 5.0 is slated to include String.trim, so it’s probably worth thinking ahead for this. In Firefox 3.5—the only current browser that I know of that supports String.trim—calls to the native String.trim run in a fraction of the time of any of the JavaScript implementations.

Note: Firefox’s native implementation of String.trim does not count U+1680 or U+180E as whitespace. It does treat U+3000 as whitespace.

¹Yes, I wrote “JavaScript” and “reasonable memory consumption” in the same article. Go ahead and snicker.

Working Consciously In The Dish Room

Dan Breslau — Mon, 21 Sep 2009 16:41:34 +0000

Rack. Rinse. Wash. Stack.

I recently spent some time working as a dishwasher at a camp. No, I wasn’t sampling a possible new career. Truth be told, I was volunteering, and I enjoyed the work.

If that raised the brow over your mind’s eye, you’re not alone. Telling folks that I enjoyed this work raised any number of brows. To the naive observer, washing dishes doesn’t look like a very glamorous occupation. A closer inspection reveals just how very correct this naive observation is. Yet I drew myself into the task through working consciously—a term that I previously used in How To Make Mistakes, but never fully defined.

Working consciously makes mindful work of the mindless. It involves constantly challenging oneself to be more effective. It requires continuous awareness of the work, an ongoing search for better approaches to the task, and the willingness to try different methods and compare the results. It means, in short, attaining satisfaction by not being satisfied.

But I still haven’t defined it very well. Perhaps this example will help.

Rack. Rinse. Wash. Stack.

At its most basic, the dishwashing process comprises four tasks:

Dirty dishes are placed into racks.
The racks are sprayed, removing any excess bits of food.
The racks are run through an industrial-style dishwashing machine (the Hobart).
After coming out of the Hobart, the newly clean dishes are stacked on their shelves.

When dirty dishes are coming at a fast and furious pace, we need to keep the pipeline flowing, or we’d get overrun with dirty dishes. Rack. Rinse. Wash. Stack. The racks with pegs are for plates and bowls; there’s another kind for beverage cups; flats are for utensils and various other implements of mass consumption.

Loading each rack to its capacity allows for fewer runs of the Hobart, saving water and energy. But fully loading the racks requires time and attention; too much of either creates a bottleneck. So there’s a bit of a Tetris-like challenge in loading the racks, except that the game doesn’t end just because you’re too stacked up.

The Hobart cycle takes two minutes. If the racks aren’t packed well, then the queue of racks going into the Hobart gets stretched out, making the Hobart another potential bottleneck. Yet the Hobart runs for only two minutes, not enough time to thoroughly scour dirty dishes. Hence we pre-rinse so that the dishes don’t come out of the Hobart needing another run through it (or maybe two). However, more thorough rinsing may require more time and more hot water. And sometimes a very quick scrub works better than a rinse, saving water—but scrubbing can be slower than rinsing.

Working consciously helped me to recognize these constraints; it also helped me consider and test various ways to manage them. As one example, I tried varying the orientation of the dishes in the racks; I saw that an edge-on angle let me rinse them more effectively. In the same vein, I sought other ways to minimize how much water I used when rinsing, and to recognize when the better tool was the scrub sponge and not the sprayer.

Through working consciously, I turned what could have been dull work into a win for all: Our diners had clean dishes; the task was done more efficiently; and I gained the satisfaction of seeing my work improving (along with my Tetris game). Plus, I turned a dishwashing gig into a blog post.

Even a dish room can offer interesting challenges, if you remember to look for them.

Rack. Rinse. Wash. Stack.

Filling The Cracks

Dan Breslau — Wed, 22 Jul 2009 22:19:37 +0000

The latest posted version of SyntaxHighlighter is here. For the change history, or to download older versions from this site, see the downloads page.

SyntaxHighlighter can display line numbers on the left side of the code block, in an area called the gutter. As a result of other changes that I’d made, the gutter sometimes showed gaps between the line number elements. I added some JavaScript to resize the number elements so that they’d be contiguous, closing any gaps. However, that code needs the offsetHeight for each line in the code block. As I then discovered, when JavaScript so much as reads the offsetHeight of an element, it’s likely that the browser will need to reflow the page to calculate the value. Repeat that for enough lines, and you’ve got a bit of a performance issue (or I do, depending on how you look at it.)

At one point, I’d thought that I could bypass the height adjustment for the most common cases (e.g., text lines that are short enough not to wrap.) But life and HTML come with few guarantees; testing showed that some browsers, in some environments, would still produce some 1-pixel gaps like so:

Gutter, left, showing unwanted white lines. (The text on the right is blurred; do not adjust your eyes.)

(The gaps appeared below lines that had keywords highlighted in boldface fonts. Depending on the fonts that the browser is using, the boldface can sometimes add a pixel to the height of the text line.)

Sometimes the best way to solve a problem is to make it no longer be a problem. I’d caused the gaps to appear by changing how backgrounds are rendered. In the original SyntaxHighlighter, the number elements are transparent; the gutter’s background is the background of the top-level

for the entire code block. There may be gaps between the number elements, but those gaps can’t be seen. I couldn’t easily go back to that approach, but thinking about it inspired a new one: By stretching the first gutter element vertically, it could be used to provide the background for the gutter. The remaining gutter elements would then be laid out over that first one. Here’s an illustration:

The first number element fills the gutter vertically; the remaining elements are placed on top of it, leaving no visible gaps.

The gaps are invisible once more. The associated JavaScript still causes some reflow, but no more than five times per code block, a much smaller overhead in most cases.

Dumping Hack Flash, It’s a Class, Class, Class

Dan Breslau — Fri, 10 Jul 2009 23:37:49 +0000

The latest posted version of SyntaxHighlighter is here. For the change history, or to download older versions from this site, see the downloads page.

Well, that was… interesting.

I’ve been working on improvements in SyntaxHighlighter’s whitespace handling. My goal was to have whitespace presented exactly as it’s supplied within the original HTML. I thought this would be helpful on two fronts: First, it might fix a few minor display formatting issues that I’d found. Second, and of greater concern to me, I figured that if SyntaxHighlighter preserved whitespace well enough, then it would be OK to remove the Flash-based “Copy” applet from the toolbar. (I’m not sure, but my guess is that the Flash app was added because copying the code to the clipboard has been so problematic.)

I’ll admit that its removal is a mixed blessing: It’s not like it’s a bad thing, to be able to copy the code to the clipboard with one click of the mouse. But the Flash applet carries some baggage, too: It requires Flash (well, yeah); it adds to the overall footprint consumed by SyntaxHighlighter (especially when using Internet Explorer); and it doesn’t always work.

I don’t have a lot of details on that last one; then again, I haven’t sought details. But the problem could simply be that Flash 10 added new restrictions on the application’s access to the Clipboard, thereby breaking it for SyntaxHighlighter.

Maybe, maybe not. But if the traditional select-and-copy operation worked as expected, without loss of newlines or other whitespace, would there really be any further need to keep the Flash script? I didn’t think so either.

I think I can hear some of you snickering. No, I hadn’t ever gone down this road before. So, I’ve discovered that perfect whitespace preservation in HTML is not easy. It may not even be possible, even setting tab characters aside.

I’d hoped to come up with a broadly cross-browser-compatible scheme for preserving whitespace in the display and in the paste buffer. What I have is a combination of JavaScript and CSS classes that fake it pretty well (I think.) The key, of course, lies in using the CSS whitespace="pre" and whitespace="pre-wrap" directives in the appropriate classes. JavaScript is needed, among other things, to ensure that line breaks come through correctly. And yes, I did have to break into browser-specfic code at times.

Surprising things can happen to space characters ‘twixt the HTTP stack and the paste buffer. Throw in newlines and tabs (On second thought: no, don’t throw in tabs; throw them out), and life gets very interesting indeed.

While the resulting release doesn’t quite fit the criteria for being WYSIWYG, I’d say it does at least satisfy YCAGWYWBIYTSYJMFYGWYN. Tab characters are converted to spaces, and there are often one or two spaces added at the ends of lines. I’m guessing that this will be close enough for most uses. For those cases where exactness is required, there’s still the toolbar command for view the original source as plain text. The popped-up text preserves the original whitespace, and a “copy” works just fine there. Putting this all together, it did seem to me that the Flash app could now be dropped, and so I’ve done so.

I’ve also added some tentative support for titles. Unfortunately, I can’t show an example in this post, because the WordPress Plugin doesn’t support the option yet; but you can see an example here. (I’d thought about adding this previously, then discarded it as creeping featurism, and then re-considered it when I realized that it might be of use for the visually disabled.)

And there are a lot of changes under the hood; I’ll write about these in separate posts.

Occam’s Razor and Brushes

Dan Breslau — Mon, 29 Jun 2009 17:22:12 +0000

There’s no new ZIP file for this post. I have yet another set of changes in the works, which should be ready shortly. I’ll post a ZIP file then, with both sets of updates.

Alex Gorbatchev’s SyntaxHighlighter uses separate modules (Brushes) to process the syntax for individual programming languages. A web page that uses SyntaxHighlighter must load the main JavaScript file (shCore.js), and load the required brush files. After the brushes are loaded, the page sets any desired configuration parameters for the highlighter, then invokes SyntaxHighlighter.all, which performs the formatting and highlighting.

SyntaxHighlighter currently includes 21 brushes, each in its own JavaScript file. A web page author may wish to load only those brush files that are needed for a given page. David Chambers addressed this by using JavaScript to request the needed brushes from the server. The first time that I browsed his site, using Firefox, this worked well. But the second time, using Internet Explorer, an error message popped up in my browser window:

David’s script worked by extending the page’s with a new