Comments on: jQuery and Performance: What is ‘this’?

By: Tim Branyen

Tim Branyen — Tue, 02 Feb 2010 16:03:49 +0000

Regarding premature optimization, I don’t think anyone is claiming to refactor code to use this approach. I do, however, feel its prudent as a client side coder to know where performance can be improved, without taking away from the readability. While many of us are on quad core machines that show minute differences with events. Its very likely a user could be on an older machine that stands to gain.

I agree with premature optimization being an unnecessary step in the development cycle, but with this new knowledge, it instead becomes good practice.

I also noticed through some testing of my own that getElementsByTagName performed faster than access forms and images through dot-notation.

By: JAlpino

JAlpino — Mon, 11 Jan 2010 23:35:28 +0000

Like any type of app development, it’s best not to get caught up in pre-mature optimization. So @Adam, if your app is not heavy on the client side, then taking optimization steps such as using the dom properties directly vs. jQuery calls, then it might not make sense to switch. However, if that’s not the case then applying these performance measures will help, even if the calls span over time rather than all at once.

By: Adam Koch

Adam Koch — Mon, 11 Jan 2010 14:20:24 +0000

Sure, but this is for 20-50k times. I don’t have any functions that are called that many times.

By: Jonas De Smet

Jonas De Smet — Sat, 09 Jan 2010 11:08:59 +0000

Wow, thanks for the great tip, there were a couple of things I didn’t know!

By: Dean Hall

Dean Hall — Sat, 09 Jan 2010 04:43:16 +0000

Seeing all the qualifiers, this seems to prove the point that jQuery (and other, similar libraries) is invaluable to developers writing cross-browser JS. Thanks for the reminder, though, that libraries also invisibly add cycles. It won’t affect us much when developing sites with minimal JS that’s executed once or even on occasional user interaction, but when writing complex web apps, knowing how to optimize the code that gets executed repeatedly will save your users lots of headaches.

By: Kartik Sehgal

Kartik Sehgal — Fri, 08 Jan 2010 06:16:39 +0000

@Eric Thanks for sharing this information. I was not sure if getAttribute was faster on all the browsers, but I too faced problems similar to the ones mentioned in http://updatepanel.wordpress.com/2008/12/31/more-on-getattribute-setattribute-and-the-value-attribute/ when trying to use getAttribute and setAttributes while sorting list boxes.

By: Eric Hynds

Eric Hynds — Thu, 07 Jan 2010 23:17:00 +0000

Wow, I cannot believe getAttribute() is that much faster… I’ve added this benchmark to my original post. I did some research and found a good post on the differences between this.property and this.getAttribute(): http://updatepanel.wordpress.com/2008/12/31/more-on-getattribute-setattribute-and-the-value-attribute/

As it turns out, getAttribute() will return the string value set in the original markup regardless if it is changed later by JS. this.property notation returns the current value. Just something to be careful of…

By: JAlpino

JAlpino — Thu, 07 Jan 2010 22:30:25 +0000

@Kartik Just wanted to point out that you can use the getAttribute() and setAttribute() methods on the dom node to get around the lack of a ‘public’ property such as ‘for’ on a label.

Another interesting point is that in all browsers that I tested this on; FF(3.5.6), Chrome(3.0.195.38) and IE(8.0.6001.18702), getAttribute() performed much better (4x) than straight object.property notation.

Add the following profile statement to the first test:

profile('vanilla javascript using getAttribute()', function(){
			href = self.getAttribute("href");
		});

** setAttribute() on the hand, had mixed results. In FF in ran in the same time as the object.property = ‘value’; notation, but in Chrome and in IE it was much slower.

By: Eric Hynds

Eric Hynds — Thu, 07 Jan 2010 21:31:11 +0000

@JAlpino nice! This calls for a graph, I’ll have to whip one up. I’m real surprised there was no improvement in Chrome using jQuery vs. JavaScript.

@Kartik good point. It’s harder to see what is available to ‘this’ because, unlike a jQuery collection, logging it to the console doesn’t reveal it’s properties.

By: Kartik Sehgal

Kartik Sehgal — Wed, 06 Jan 2010 14:59:16 +0000

Nice Article! One limitation of using this directly is that the number of attributes supported are very minimal. Take the label tag for instance. It has an attribute “for”. this.for does not execute. In fact it gives a JavaScript error. Then there is also a question of consistency. It will take greater effort in ensuring that this is being used directly correctly, especially when working in large teams.