Anyway, my current project involves working on a dojo-based web app with a little over a half-million lines of just *javascript* code on the front end (Don't even get me started on the server side stuff... we even have ancient X server calls in there). In short, if we have a problem in many parts of the code base, it can cause a noticeable slowdown to the end user. Earlier this evening, I decided to do the unthinkable and take a look at the JSLint output on the nightly build to see what people were ignoring. It turns out that there were a few hundred missing semi-colons. So, I did as any card-carrying nerd would do. I ran a ton of tests to see if semicolons actually matter.
What I found out isn't exactly surprising, but it's not something to ignore either. My test consisted of a very repetitive block of code called over and over. It's not exactly bullet-proof scientific, but it shows that something is going on here. In Firefox 2.0.0.17, Firebug's profiler turned up the following (averages) when running this line about 3,000 times with and without semicolons:
document.getElementById("blah").innerhtml = "foo";
Test 1:
With semicolons: 19.3ms
Without semicolons: 23.8ms
So, I then bumped up the number of times it calls the line to about 400,000. Using the magic of vim's regex support, I created a file with and without the semicolons. The difference pretty much jumps out. Remember, the only difference in the file is the existence of semicolons.
Test 2:
With semicolons: 2344.275ms
Without semicolons: 2531.817ms
A quick test in Firefox 3.0.3 comes up with the same ratios for the smaller file. The larger file just gave me a "ran out of stack size" error, which I found odd, since the code just sets a node over and over again. Perhaps it has something to do with Firefox's parse tree on a 35M js file?
Anyway, there you go folks. Remember your semicolons. If your users have been screaming at you because of that pesky 4ms slowdown, they'll thank you for the speedup. Well... maybe not :)
No comments:
Post a Comment