My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Tuesday, September 26, 2006

Are speed tests really usefull for developers ?

Yesterday my favourite portal has posted a speed test inside its blog.
This JavaScript benchmark was posted on this site.

I think that those kind of tests are only a "point of view" and aren't comparable with real javascript usage.
As I've showed on my for and while loop test, every operation is a single case to analize and every single case has not everytime the same result.

For example using a for and an <= expression with every loop should be faster in some browser and should be slower in some other.
Then it's not always a good way to compare some internal loop operations because a browser should be faster to push a string inside an array but should be slower to execute that kind of for loop.

Often speed depends on garbage collector too, that should be faster in some point of execution and slower in some other.

These concept are true with every other benchmark of that site.

Math engine, as Ajax declaration, are faster with FireFox and really bad with IE because the object has a dedicated try catch for every IE browser.
I usually don't use that way to declare an XMLHttpRequest then my library should be faser than Opera with IE too.
If you change some piece of execution code, you can see that IE6 or 7 is even slower than FireFox with some function.

What I mean is that a real "every day" application will "never" use 4000 try catch but should use a lot of Math operations and DOM elements using many array and Ajax declarations too.
Every Ajax object or class should be simple or really complex and some browser should declare it faster or slower than other one.

Another generic relevant thing is code optimizzation ... you could use "only Opera" to surf the web but if a library contains bad practices its code execution will be slow in every case.

And again, the use of "var" before every temporary variable should be slower or faster, look at the MathEngine function ... is this usefull ?
is this a real application example ?

The StringFuncs has 2 operations that are only for human eyes because if you don't call those functions how can you test them ?

str.toLowerCase; // yeah! a string has a toLowerCase prototype ..
str.toUpperCase; // yeah! a string has a toUpperCase prototype ..

// P.S. I think that He's just forgot it :)

A "StringBuilder" function should be a better test too because every JS developer knows that using string += something isn't a good speed practice and the use of concat instead of '+''+''+''+''+' ... is faster too.
A StringBuilder operation is not different from array.push, but doesn't use sort and reverse as ArrayFuncs does.

Is a StringBuilred competition another usefull test to do ? I think that ...

function StringBuilder() {
function StringBuilder() {
this.append = function(what){
this.toString = function(){
return arr.join("");
var arr = [""];
var startTime = getTime(), i = 4001, sb = new StringBuilder;
sb.append("a piece of code".concat(i));
sb = sb.toString();
var endTime = getTime();
getElement('speed_sb').innerHTML = (endTime - startTime);
getElement('speed_total').innerHTML = eval(getElement('speed_total').innerHTML) + (endTime - startTime);

... and Should we care about few milliseconds ?

Then this is what I think: these speed tests are a must only for Rhino or SpiderMonkey developers because a javascript developer doesn't need to care about performances (in this way) ... He needs to care about generic code optimizzations using lightweight code implementations without redundant operations inside a cross-browser code.
That's what a developer should care about, not dedicated speed test for this or that function.

Finally, this is a revisited version of that benchmark, enjoy with it, don't care about it!

See you :)


Anonymous said...

Humm... i think speed tests are useful! but i wonder if your testing suite wasnt a bit too much stuffed - all loop results where different all the time. Nevertheless, i think memory leaks are the thing to really care for these days instead of speed...

another things regarding ACE: how about a switch to turn off JSL in the outputtet script? that would avoid overhead if i want to include more than one php class (is this possible anyway??)

Good evening :)

- Johannes

Andrea Giammarchi said...

how about a switch to turn off JSL in the outputtet script?
why you should turn off JSL where there isn't any overhead since ACE can be called using more than one class as query string ?

more than one class ?

src="ACE.php?ClassOne|ClassTwo|ClassTrhee" ... that's all, any overhead, JSL is included only one time, then pelase read ACE Documentation and Examples before this kind of question :)

P.S. ACE is Off Topic in this post

Anonymous said...

Still ot but: Brilliant! must have overlooked that option for including many classes!

kentaromiura said...

Opera is very slow in some cases,
try this script in Opera, for example:

Andrea Giammarchi said...

consider that my first bytefx example was based on dinamyc background created with a big loop ... then I've removed this loop and add an image because Opera didn't move quickly the simple trasparent div ;)