Native Element#classList in FF 3.6 Against RightJS

As many of you probably aware, FF 3.6 has the HTML5 Element#classList feature implemented natively. And then @DouweM asked if we could add it to RightJS.

Well, I tried, but the thing is that those guys at Mozilla could do it better. They have the test, the picture and yet another 2x times performance improvement, awright.

But lets check it out by ourselves, shall we?

I've created this little script which has two implementations, one uses FF 3.6 native feature, another one uses the same pure JavaScript algorithm we use at RightJS to handle css-classes. And here's a screenshot of my test-run.



Seems like RightJS implementation murks a native feature again. It's more than three times faster on classes adding :)

So how did those guys at Mozilla get their results?

They simply used lousy RegExp based implementation of the feature in their test. Surely it was slower.

This is pretty much it. Hope they will fix it in the next releases of FF.

Recent jQuery Performance Updates

Now folks, you know, I was always saying "there is nothing like a smell of good statistics in the morning!". Now lets take a look at that 2x speed up claimed over here.

I'm using my Shakker util to perform the tests. You can also read why I don't use Taskspeed anymore.

So to the tests. Lets take a look at the Firefox test



Yea, kind a bit of speed up at claimed `bind`, `html` and `remove` methods, certainly not 2x, and note how it actually got slower at 1.4.1 and then gets back to almost the same values as 1.4.0.

Now lets take a look at the same thing at Safari



A different scale, the same picture, it's getting slower from 1.4.0 to 1.4.1 and then gets back to almost the same values at 1.4.2. No 2x speed up between 1.4.2 and 1.4.1, more of that almost no speed up at all and certainly no 3x speed up agains 1.3.2.

Well, lets get further and take a look at the test in another fine browser, Chrome.



The same exact picture with the `bind`, `html` and `remove` methods, got slower on 1.4.1 and to the same value at 1.4.2.

Now you should get back to that release notes page and ask yourself "why there are no results for version 1.4.0?".

Yup, because there is no speed up, they merely fixed their own fuckups in 1.4.1 and now present it as 2x speed boost.
Awesome! :)

Slowing Things Down Under OS X

You know what they say "you need to slow down to see some certain things". In case of web-development, sometimes you need to emulate a realistically slow internet connection to see some problems with your project. See how quickly it loads up, how it receives the images, especially it useful to test file-uploads and ajax operations. So here is a little tip how can slow down requests to your local server to test the things properly.

Under OS X you have access to the FreeBSD traffic shaping util ipfw. First of all you need to define some rule which will work on local interactions.

sudo ipfw add 1 pipe 1 src-ip 127.0.0.1
sudo ipfw add 1 pipe 2 dst-ip 127.0.0.1

After that we can set up the connection speed, and also I like to add some delay to emulate a request to a remote server

sudo ipfw pipe 1 config bw 40Byte/s delay 100ms

After that all your local requests will slow down to 40Byte/s speed with a realistic 100ms response delay.

When you have done with your tests, you can remove the rule with the following command.

sudo ipfw delete 1

Now it is all interesting but lets wrap it up in a simple shell script so we didn't need to memorize all the fancy calls.

sudo touch /usr/bin/slowdown
sudo chmod +x /usr/bin/slowdown

After that open the file with your favorite editor and write the following little script

#!/bin/bash

if [ $1 = "clear" ] ; then

  ipfw delete 1
  
else
  
  ipfw add 1 pipe 1 src-ip 127.0.0.1
  ipfw add 1 pipe 2 dst-ip 127.0.0.1
  ipfw pipe 1 config bw $1KByte/s delay 100ms
  
fi

Now you can create and remove pipes just like that

sudo slowdown 40

And to remove the rule call it like that

sudo slowdown clear

That's all about it. Happy testing!