Kraken Info

This info is for Kraken 1.0.

ai-astar

A toy benchmark. A path-finding program that uses A* search.

Key features. The benchmark spends almost all of its time in the loop in the following function.

Array.prototype.findGraphNode = function(obj) {
    for(var i=0;i<this.length;i++) {
        if(this[i].pos == obj.pos) { return this[i]; }
    }
    return false;
};

Mozilla-specific things. The above loop is traced and accounts for roughly 95% of execution time.

audio-beat-detection

This is identical to audio-fft, except it has an insignificant amount of extra stuff at the end.

imaging-desaturate

Description. A kernel. A 400 x 267 image is represented as an array where each pixel gets four consecutive elements, representing its R/G/B/Alpha values. All values are in the range 0..255. The program transforms the contents of the array.

Key features. Almost all the benchmark's time is spent in this loop:

while (p--)
    data[pix-=4] = data[pix1=pix+1] = data[pix2=pix+2] = (data[pix]*0.3 + data[pix1]*0.59 + data[pix2]*0.11);

It iterates through each pixel, setting the R/G/B values all to the the same value, which is a function of the prior R/G/B values.

This desaturation loop is repeated 200 times. The first time the desaturation loop runs, the (R, G, B) values are converted from integers to doubles. The remaining 199 times, the values are doubles to begin with.

The program is kind of stupid for (a) not truncating the desaturated R/G/B values and (b) desaturating the image 200 times in a row. Indeed, the benchmarks admits as much for (b):

//XXX improve dataset rather than loop
for (var pixcounter = 0; pixcounter < 200; pixcounter++)
    Pixastic.Actions.desaturate.process(params);

Bug 603841 is open to change this behaviour.

Mozilla-specific things. The trace code generated assumes the array elements are integers, because that's what is seen at record-time, but in the end 99.5% of the time it's not, so we end up taking a particular side-exit every time to a second trace fragment.

If bug 603841 isn't fixed, it would be good if we could somehow (using the oracle?) detect that the side-exit is hot and recompile the fragment.

json-stringify-tinderbox

A microbenchmark. Calls JSON.stringify() 1000 times on an object that takes up over 450,000 chars to express in a file.

Key features. The result of the call to JSON.stringify() is never used, so this benchmark is susceptible to gaming -- an implementation could detect that the result isn't used and call a faster version of JSON.stringify() that doesn't build the result (ie. an empty function).