I was doing this test case to see how much using the this selector speeds up a process. While doing it, I decided to try out pre-saved element variables as well, assuming they would be even faster. Using an element variable saved before the test appears to be the slowest, quite to my confusion. I though only having to "find" the element once would immensely speed up the process. Why is this not the case?

Here are my tests from fastest to slowest, in case anyone can't load it:

1

$("#bar").click(function(){
    $(this).width($(this).width()+100);
});
$("#bar").trigger( "click" );

2

$("#bar").click(function(){
    $("#bar").width($("#bar").width()+100);
});
$("#bar").trigger( "click" );

3

var bar = $("#bar");
bar.click(function(){
    bar.width(bar.width()+100);
});
bar.trigger( "click" );

4

par.click(function(){
    par.width(par.width()+100);
});
par.trigger( "click" );

I'd have assumed the order would go 4, 3, 1, 2 in order of which one has to use the selector to "find" the variable more often.

UPDATE: I have a theory, though I'd like someone to verify this if possible. I'm guessing that on click, it has to reference the variable, instead of just the element, which slows it down.

I was doing this test case to see how much using the this selector speeds up a process. While doing it, I decided to try out pre-saved element variables as well, assuming they would be even faster. Using an element variable saved before the test appears to be the slowest, quite to my confusion. I though only having to "find" the element once would immensely speed up the process. Why is this not the case?

Here are my tests from fastest to slowest, in case anyone can't load it:

1

$("#bar").click(function(){
    $(this).width($(this).width()+100);
});
$("#bar").trigger( "click" );

2

$("#bar").click(function(){
    $("#bar").width($("#bar").width()+100);
});
$("#bar").trigger( "click" );

3

var bar = $("#bar");
bar.click(function(){
    bar.width(bar.width()+100);
});
bar.trigger( "click" );

4

par.click(function(){
    par.width(par.width()+100);
});
par.trigger( "click" );

I'd have assumed the order would go 4, 3, 1, 2 in order of which one has to use the selector to "find" the variable more often.

UPDATE: I have a theory, though I'd like someone to verify this if possible. I'm guessing that on click, it has to reference the variable, instead of just the element, which slows it down.

• javascript
• jquery

• 1 And even faster still (AND immune to the side-effects of testing): (document.getElementById('bar').onclick = function() {this.style.width = this.offsetWidth+10+"px";})(); – Niet the Dark Absol Commented Mar 24, 2014 at 8:42

5 Answers 5

Fixed test case: http://jsperf.com/this-vs-thatjames/10

TL;DR: Number of click handlers executed in each test grows because the element is not reset between tests.

The biggest problem with testing for micro-optimizations is that you have to be very very careful with what you're testing. There are many cases where the testing code interferes with what you're testing. Here is an example from Vyacheslav Egorov of a test that "proves" multiplication is almost instantaneous in JavaScript because the testing loop is removed entirely by the JavaScript compiler:

// I am using Benchmark.js API as if I would run it in the d8.
Benchmark.prototype.setup = function() {
  function multiply(x,y) {
    return x*y;
  }
};

var suite = new Benchmark.Suite;
suite.add('multiply', function() {
  var a = Math.round(Math.random()*100),
      b = Math.round(Math.random()*100);

  for(var i = 0; i < 10000; i++) {
     multiply(a,b);
  }
})

Since you're already aware there is something counter-intuitive going on, you should pay extra care.

First of all, you're not testing selectors there. Your testing code is doing: zero or more selectors, depending on the test, a function creation (which in some cases is a closure, others it is not), assignment as the click handler and triggering of the jQuery event system.

Also, the element you're testing on is changing between tests. It's obvious that the width in one test is more than the width in the test before. That isn't the biggest problem though. The problem is that the element in one test has X click handlers associated. The element in the next test has X+1 click handlers. So when you trigger the click handlers for the last test, you also trigger the click handlers associated in all the tests before, making it much slower than tests made earlier.

I fixed the jsPerf, but keep in mind that it still doesn't test just the selector performance. Still, the most important factor that skewes the results is eliminated.

Note: There are some slides and a video about doing good performance testing with jsPerf, focused on common pitfalls that you should avoid. Main ideas:

• don't define functions in the tests, do it in the setup/preparation phase
• keep the test code as simple as possible
• compare things that do the same thing or be upfront about it
• test what you intend to test, not the setup code
• isolate the tests, reset the state after/before each test
• no randomness. mock it if you need it
• be aware of browser optimizations (dead code removal, etc)

You don't really test the performance between the different techniques.

If you look at the output of the console for this modified test: http://jsperf.com/this-vs-thatjames/8

You will see how many event listeners are attached to the #bar object. And you will see that they are not removed at the beginning for each test.

So the following tests will always become slower as the previous ones because the trigger function has to call all the previous callbacks.

Some of this increase in slowness is because the object reference is already found in memory, so the compiler doesn't have to go looking in memory for the variable

$("#bar").click(function(){         
    $(this).width($(this).width()+100); // Only has to check the function call
});                                     // each time, not search the whole memory

as opposed to

var bar = $("#bar");
...
bar.click(function(){
    bar.width(bar.width()+100);         // Has to search the memory to find it 
});                                     // each time it is used

As zerkms said, dereferencing (having to look up the memory reference as I describe above) has some but little effect on the performance

Thus the main source of slowness in difference for the tests you have performed is the fact that the DOM is not reset between each function call. In actuality, a saved selector performs just about as fast as this

Looks like the performance results you're getting has nothing to do with the code. If you look at these edited tests, you can see that having the same code in two of the tests (first and last) yield totally different results.

I don't know, but if I had to guess I would say it is due to concurrency and multithreading.

When you do $(...) you call the jQuery constructor and create a new object that gets stored in the memory. However, when you reference to an existing variable you do not create a new object (duh).

Although I have no source to quote I believe that every javascript event gets called in its own thread so events don't interfere with eachother. By this logic the compiler would have to get a lock on the variable in order to use it, which might take time.

Once again, I am not sure. Very interesting test btw!