JavaScript Rules - performance

Web Metrics Framework

2010-08-25T00:00:00-07:00

Recently Google Web Metrics report came across and inspired by my co-worker Stoyan Stefanov’s WTF - Web Testing Framework I decided to build my own ruleset for YSlow using these metrics to check how good or bad pages are compared to Top and All Sites averages.

Last edition of O’Reilly Velocity Conference, Stoyan demonstrated how easy is to build your own YSlow ruleset and following his post and source code I was able to make it. This first release of this extension of extension of extension features:

Google Web Metrics from 2010-05-26
Top and All Sites metrics rulesets
Use percentile to score when available
Use SSH metrics for HTTPS pages

Gimme!

The code is in GitHub
Install it from Mozilla Addon Page or Download Page

Usage

After installing this extension you will see 2 new rulesets in the YSlow rulesets drop down list:

Web Metrics Framework - Top Sites
Web Metrics Framework - All Sites

Choose one of these rulesets and click Run Test button. The current page will be evaluated using the Google web metrics data.

Metrics

The metrics provided by Google on its article are mainly averages with some percentiles and SSL data. YSlow rules need a lint function that evaluates an input returning a score from 0 to 100 which is later used to give the F to A score system using weights.
Since not all metrics have percentiles I had to compare the page metrics with the average multiplied by a magic number (4) to create a range from 0 to 4 * average (if any statistic savvy here has comments on it please help me out to find a better way to evaluate) which is good enough to have an outcome where being in the average deserves a C. Perhaps Google releases new reports in future updates with all metrics percentiles, this extension could benefit from those numbers and become more accurate.
If the page being checked is secure (HTTPS), the SSL data available on the report is used instead. The weighting distribution was given by:

Every metric starts with 1
Metrics with percentile get 1 more
Metrics directly related to wire traffic payload or number of requests also get 1 more

Again: statistics savvy, help me improving this extension with your valuable feedback

Conclusion

Although these metrics aren’t 100% accurate (see Caveats section on Google’s article) it’s a good resource to compare your site with a sample of several billion pages crawled by Googlebot. Have fun!

WARNING: Like JSLint, Web Metrics Framework might hurt your feelings :-)

DISCLAIMER: This extension is not related with Google Inc. or Yahoo! Inc.

New posts about performance. Back and alive!

2010-04-27T00:00:00-07:00

After a long period of no posts due to personal issues, I’m back now and alive!
This time with a new post on YDN - Yahoo! Developer Network - blog: Performance on Yahoo! Search for Earth Day.
In this post I describe the performance case study of Yahoo! Search Earth Day campaign.

During this long off-post period, besides my day job, I’ve been doing some experiments, developing some tools and brainstorming lots of ideas, mostly related to performance and JavaScript. I do have some post drafts and will be publishing them soon. Here are a few topics I’m covering along this year:

setTimeout minimum delay limit
Prefetching CSS images
Problems with gradients filters on IE links hover
Flipping page direction RTL/LTR easily - RTLzr a Firefox extension
JavaScript Interviews Exposed (series)
Lazy Enhancement
JavaScript video subtitle
JavaScript video timeline marks
Deleting a removed node from DOM

Stay tuned!

Fast min/max in arrays

2009-09-23T00:00:00-07:00

This morning while commuting to the office, reading JavaScript for Web Developers, I bumped into a question: how could I improve a well known algorithm that gets the smallest or the largest number in an array by using built-in Math methods such as Math.min and Math.max. For those not familiar with these methods, they return the smallest or the largest number respectively from a list of zero or more numbers passed as parameters, e.g.: Math.min(4,3,9,6) returns 3, Math.max(4,3,9,6) returns 9. I was wondering if calling such methods using apply and an Array as argument would work. I could hardly wait to get to the office to test it out on my Firebug console. I first tried:

Math.max.apply(Math, [4,8,3,5,1,2]);

And bingo! It works!

Previous work

Since it seemed so easy I thought that somebody else would had already figured this out before and I did a quick search for Math.max.apply and *bam!*: the first occurrence was a John Resig’s post back in 07’s where he describes such technique for augmenting Array type. Really handy.

Performance

My main concern to decide whether to use this technique was its performance, so I ran a quick test comparing it to a very popular for loop algorithm and an optimized loop for a given array of random numbers:

var i, max,
    a = [],
    len = 1e4;

/* create an array of ten thousand random numbers */
console.time('array creation');
for (i = 0; i &lt; len; i += 1) {
    a[i] = Math.floor(Math.random() * 1e4);
}
console.timeEnd('array creation');

/* for loop */
max = -Infinity;
console.time('for loop');
for (i = 0; i &lt; len; i += 1) {
    if (a[i] > max) {
        max = a[i];
    }
}
console.timeEnd('for loop');
console.log(max);

/* optimized loop */
max = -Infinity;
i = len;
console.time('optimized loop');
while (i--) {
    if (a[i] > max) {
        max = a[i];
    }
}
console.timeEnd('optimized loop');
console.log(max);

/* Math.max */
console.time('Math.max');
max = Math.max.apply(Math, a);
console.timeEnd('Math.max');
console.log(max);

Running this code on my firebug console (Firefox 3.0.14), I got the same largest number on each technique within the array as expected and the following times:

array creation: 89ms
for loop: 29ms
optimized loop: 20ms
Math.max: 1ms

Wow! This is pretty fast! Huh? You can copy the code above and paste on your firebug console in order to get your own results or you can check it out here.

Conclusion

This technique deserves lots of credit for its simplicity and speed, it’s those one-line codes that beats any fancy and complex algorithm that once you get to know, you start using every time you need, however it’s not true for all browsers :-(

WebKit Page Cache

2009-09-17T00:00:00-07:00

Performance on the web has always been a hot topic to talk about specially when you talk about page load, but you don’t see as often people talking about perceived load which is related to how fast the interface responds to the user interaction, in this area WebKit based browsers like Safari and Chrome from my point of view have always been ahead.

In the article WebKit Page Cache I - The Basics Brady Eidson talks about the Page Cache feature on WebKit, as he stated it’s not about caching in the HTTP sense, storing raw files on disk or even caching resources in memory. “More simply, when you leave the page we pause it and when you come back we press play.”, this totally affects the perceived performance, when you hit the back button, even if you have files cached locally the browser will still have to load it again, run all your scripts, recreate the DOM and so on, so basically “When the Page Cache works it makes clicking the back button almost instantaneous.”

The last time they updated Page Cache was back in ‘02 the web has evolved a lot since then and it’s not easy to keep up to date, you have to take in considetration HTTPS, plugins, frames, page events, although some of these issues have been fixed already like the frames problem, it still a long way to go, anyway it’s great to see that they are working on it.

String searching algorithms in JavaScript engines

2009-08-12T00:00:00-07:00

I’ve just finished chapter 7: Writing Efficient JavaScript by Nicholas Zakas on Steve Souders’ new book, Even Faster Web Sites, where he presents several string optimization techniques to improve JavaScript performance and wondered which algorithm does String.indexOf method implements on JavaScript engines (aka ECMAScript engines).
A few months ago I’ve asked this question to Yahoo! fellow Douglas Crockford and he said the ECMAScript standard does not require a specific algorithm, so it could vary with each browser. You can check that on section 15.5.4.7 of Standard ECMA-262. I decided then to download the most popular open-source JavaScript engines source codes and found mainly 3 algorithms:

Naïve: simple and least inefficient way to search in strings, it basically checks every position in the haystack then every position of the needle. The advantage of using this algorithm is that it needs no initial overhead such as auxiliary tables creation. It has O(mn) complexity, where m is the needle length and n the haystack length.
Boyer-Moore: Efficient searching string algorithm that preprocesses the needle and doesn’t check every position in the haystack but rather skips some of them on each unsuccessful attempt. It has O(n) complexity with O(3n) in the worst case.
Boyer-Moore-Horspool: It’s a simplification of Boyer-Moore’s algorithm with less overhear during initial needle preprocessing. It also has O(n) complexity but O(mn) in the worst case.

Algorithms by engines

The String.indexOf algorithms by JavaScript engines follows:

JavaScript Engine	Layout Engine	Browsers	String.indexOf algorithm
SpiderMonkey	Gecko	Firefox up to 3.0.*	Boyer-Moore-Horspool
TraceMonkey	Gecko	Firefox from 3.1.*	Boyer-Moore-Horspool
KJS	KHTML	Konqueror	Naïve
JavaScriptCore	WebKit	Safari up to 3.*	Naïve
SquirrelFish	WebKit	Safari from 4.*	Naïve
JScript	Trident	Internet Explorer	?
V8	WebKit	Chrome	Strategy: Naïve, Boyer-Moore-Horspool and Boyer-Moore
Linear B	Presto	Opera 7.0 - 9.50[	?
Futhark	Presto Core 2	Opera from 9.50	?
Rhino	-	-	java.lang.String.indexOf

SpiderMonkey

Implements the String.indexOf in C with some verifications in string lengths prior to run BMH algorithm in order to avoid long searching for relatively small strings.

Source code available at: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.0.13/source/firefox-3.0.13-source.tar.bz2

TraceMonkey

It has exactly the same String.indexOf implementation as SpiderMonkey but in C++.

Source code available at: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/3.5.2/source/firefox-3.5.2-source.tar.bz2

KJS

The main part of the naïve implementation of indexOf follows*:

/* ... */
for (const UChar* c = data_ + pos; c &lt;= end; c++)
    if (c->uc == fchar && !memcmp(c + 1, fdata, fsizeminusone))
        return (c - data_);

return -1;

* taken from KDE 4.0 API reference

Files related to String.indexOf method:

string_object.cpp: defines the prototype for String object where indexOf is in a switch case statement and calls find function.
ustring.cpp: defines the find function where the naïve algorithm is implemented.

Browse the source code online: http://api.kde.org/4.0-api/kdelibs-apidocs/kjs/html/files.html

JavaScriptCore & SquirrelFish

These engines are known as JavaScriptCore in WebKit Project and was originally derived from KJS, hence still shares the same algorithm for String.indexOf.

Files related to String.indexOf method:

root/trunk/JavaScriptCore/runtime/StringPrototype.cpp: this is where indexOf method is defined and call find function
root/trunk/JavaScriptCore/runtime/UString.cpp: look for find function

Source code available at: http://webkit.org/building/checkout.html
Browse the source code online: http://trac.webkit.org/browser

V8

A very smart strategy is applied to the string searching in order to choose the best algorithm based on the length of the needle:

First of all it checks if there is a non-ASCII needle for an ASCII haystack and bail out if there is.
Checks if the needle length is less than 5 then uses a naïve solution called simpleIndexOf, because the max shift of Boyer-Moore on such needle length doesn’t compensate for the overhead. This simpleIndexOf function never bails out, it means that the needle will be checked for a match in the whole haystack.
If the needle length is greater than or equals to 5 another simpleIndexOf function is called. This one considers how much work have been done (unsuccessful matches) in order to stop trying and switch for a better algorithm. This is called the “badness count” which once reached the max, stop the search and returns the index in the haystack where the next algorithm should continue from.
The next algorithm in the strategy chain is Boyer-Moore-Horspool which also consider the badness count prior to jump to the next algorithm.
The last one is Boyer-Moore which has some initial overhead when creating good and bad shift tables.

Source code available at: http://code.google.com/p/v8/wiki/Source?tm=4

Rhino

Rhino runs on top of Java Virtual Machine and uses the java.lang.String.indexOf from Java language implemented for such JVM. Interestingly there is a comment saying:

“Uses Java String.indexOf(). OPT to add - BMH searching from jsstr.c”.

Where jsstr.c is the file for SpiderMonkey JavaScript String implementation. Implementing such algorithm in Java might degrade the search performance, unless the java.lang.String.indexOf implementation is much worse than that.

Source code available at: http://www.mozilla.org/rhino/download.html

Other engines

What about Internet Explorer, Opera and other browsers JavaScript engines? As they aren’t open-source projects I could not check their codes out. :-(

Benchmark

By running a simple test across some browsers we can have an idea how fast/slow is String.indexOf on some JavaScript engines although this doesn’t necessarily mean an algorithm is better than another because the performance of the engine itself might affect the outcome.
The test consists of the average of a 100 times running a search for the word ”foobar” in the middle of a ~1200 length ”ipsum lorem” text iterating 1 million times each search. Try it yourself.

The results in the follow table were taken by running this test on the same machine (Pentium 4HT, 3GHz, 1Gb RAM, Windows XP SP3).

JavaScript Engine	Browser	Version	Average (ms)
V8	Chrome	2.0.172.39	827.66
SpiderMonkey	Firefox	3.0.13	947.97
TraceMonkey	Firefox	3.5.2	1169.25
SquirrelFish	Safari	4.0.2	1207.02
KJS*	Konqueror	4.2.2	1361.59
SpiderMonkey	Firefox	2.0.0.20	1456.57
Futhark	Opera	10.00 beta 2	1549.06
Futhark	Opera	9.64	1613.02
JScript**	Internet Explorer	8.0	3101.23
Rhino***	-	-	4103.64
JScript	Internet Explorer	6.0	4479.82
JScript	Internet Explorer	7.0	4515.08

* running on the same machine with Ubuntu 9.04 live cd
** running on a VM on a different computer
*** running on Sun JRE 6 - 1.6.0_14

Again, these results don’t prove which algorithm is the best due to different browser performances, however it is worth noting that Firefox 3.0.13 performed better than Firefox 3.5.2 on this benchmark. Internet Explorer had the worst results, it can be either the algorithm or the browser performance itself or even both. :-)