Friday, February 19th, 2010
jQuery 1.4.2: performance and a few APIs
Category: JavaScript, jQuery
jQuery 1.4.2 has been released today and it comes with some performance bumps (aggressive ones according to Taskspeed). Benchmarks are challenging, and John even calls that out:
For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $("body") selector because it’s called hundreds of times within the tests. Additionally we saw large gains by optimizing .bind() and .unbind() by a fraction of a millisecond – an inconsequential amount – especially considering that any cases where you would bind hundreds of events you would likely want to use .live() or .delegate() instead.
There are some new APIs a bunch of them around ergonomics:
In this release we’ve added two new methods: .delegate() and .undelegate(). These methods serve as complements to the existing .live() and .die() methods in jQuery. They simplify the process of watching for specific events from a certain root within the document.
For example:
JAVASCRIPT:
This is equivalent to the following code written using
.live():JAVASCRIPT:
Additionally,
.live()is roughly equivalent to the following.delegate()code.JAVASCRIPT:
The jQuery team continues to really put the pedal to the metal.
Related Content:
Congrats, good work. The race continues. Bring on Dojo vNext ;-)
Great! It has to make you wonder though, how slow and inefficient jQuery was before, and how inefficient it still is. It seems like ever few months they come out with these HUGE SPEED INCREASE announcements.. but geez, how slow was it before? makes me wonder..
Here’s a MooTools plugin to do the very same http://mootools.net/forge/p/better_event_delegation !
Good stuff! I hope for the 1.4.3 release the jQuery team adds require().
I like what is proposed here:
http://forum.jquery.com/topic/requirejs-as-a-require-for-jquery
“For example, we saw significant overall performance speed-ups in Taskspeed simply by optimizing the $(“body”) selector because it’s called hundreds of times within the tests.”
So… That shiny graph at the top is relevant if your app is silly enough to call $(‘body’) hundreds of times. (?)
var body = document.body; // No jQuery necessary
:)
So, where is the article on My Library?
/points David Mark to ‘contribute news’ link in top menu.
David, we meet again. As with your posts on the Dojo list, please be mindful of your tone, as it tends to be overly aggressive and offputting.
Is you “My Library” the modified version of Dojo? In that case, I’d imagine that only people on the dojo-committers mailing list are aware of it, and the Ajaxian folks can certainly be excused for not following your every move. If you haven’t even given it a name yet….
I looked for info on your library, but http://www.cinsoft.net/ doesn’t work. Where/what is it?
Well, how hard should I have to look for a library that Ben & Dion should be fully aware of? At the very least, cinsoft.net should have a landing page, or David could have posted a link in his comment, rather than asking why we weren’t all fully aware of his work.
Leptons,
it doesn’t (always) matter what is faster, introducing/using a library is about community, stability, documentation… who cares how fast something is if nobody can discuss with other users, it crashes or you don’t even know how to use it properly. (theres more, but in the interest of time)
jQuery does this and this is its strength, the fact that it can compete with the streamline libraries too, and keeps getting faster… well that’s just sexy ;`x
@DavidMark.
If you wasn’t such an arrogant douche in your way of writing i might even read your posts one day. You wont change people’s view on “My Library” by trying to make jQuery look bad. Instead admit that the work done on jQuery is awesome, but there is other alternatives out there. Why do many people fail to understand that all the work done one many of these open source libraries benefits us all. I bet “My Library” would never have been what it is today without learning from all the others and that goes all the way around.
I have to agree that David’s tone and attitude is wack…
well David, I hope other people return the same courtesy to you if you ever make a mistake or have something up with code related to a project of yours…
Who said you had too, and guess what jQuery is dam stable doing this anyway, I know! also… I think it was almost a year between 1.3* and 1.4*, meh, ZzZz
Awesome, I’m looking forward to running 1.4.2. Also, does anyone know if there is a performance benefit to using delegate() in place of live(), or is it just syntactic sugar?
This sounds worrying to me. Is this optimization in any way written to help the user, or is it (as it sounds) purely to make jQuery look better in the almighty Taskspeed pissing contest? I would suggest that there are hundreds of better ways for the jQuery team to spend their time.
@davidmark it probably help to not insult peoples…
But then again, I would not expect you to do anything else.
> is there a performance benefit to using delegate() in place of live()?
Yes, but mostly because it makes setting your context very explicit. It’s possible to do with live() but with really awkward syntax. Therefore most live() calls are bound at the document level, which is very wasteful from a delegation point of view. Using delegate makes you do delegation in the best way possible, and reduces delegation overhead by like 80% or so.
> Taskspeed pissing contest?
See:
http://alex.dojotoolkit.org/2010/01/dojo-still-twice-as-fast-when-it-matters-most/
While they certainly will help the user, they likely have a more direct impact on the sort of tests in taskspeed. (IMHO the document.body optimization is smart and worthwhile) And FWIW it was less than a day of development time for John, so not a lot of time spent. :)
Benchmarks for the most part are not very useful, they are more like a guide. The $(body) example shows that if you code for the benchmark you can get outstanding numbers but in the end doesn’t really help anyway. Video card companies got caught up in the “code for the benchmark” crap a while back and reputations were harmed for years because of it.
.
As for My Library, I think i shall never try it based solely on the attitude of DavidMark. But this quote from his site I find amusing: “My Library works in browsers that do not yet exist. Furthermore, it works in theoretical browsers that may never exist.” That’s just funny.
.
But I still don’t understand this need for raw speed in most cases. So one library finishes a severe task, that most people will never actually use in a real-world project, less than half-a-second faster than another library. So what? If the library one uses completes the task at hand in a timely manner and suits the coding style of the person using it then what difference does it make?
@travisal well DOM traversal and injection can be quite slow, it can make a small difference, specially on IE, on large documents
But at this point, it’s more about the style of framework you like than speed for sure.
Despite the Ajaxian community’s general opinion of David, he’s also an epic troll by the looks of it; posting some slander and then disappearing while the rest of us reply about his general lack of humanity… xD
sixtyseconds,
I have to disagree. I’ve had an extended debate with David here, for at least a couple days past the posting of the parent article, and he did nothing of the sort. Those whose answer to David is to attack his character are both missing the point and disarming your arguments against his points (insofar as you have them). He knows quite a bit more about the subject than he tends to let on, and is quite a bit more involved in the Javascript libraries communities than he tends to let on as well.
* * *
David,
With all of the above said, I hope you’ll consider that your argument style does your own argument no justice, and you’d do well to frame your objections to jQuery (some of which are well-founded and others of which should be challenged) in a more informative and less combative manner. I said this the last time we went back and forth, and almost jumped in for another back and forth here but got distracted and I expect it’s too late to pick it back up now.
sixtyseconds,
DavidMark is not a troll. He has a deep understanding of JavaScript and browser differences. You can learn a lot from some people if you can put up with their communication style.
@eyelidlessness + @Les – I meant no offence by that remark. :) David has a very aggressive communication style, but you can’t fault the man for technical knowledge…
Hey guys , check this feature http://jqueryme.50webs.com/, a good way to use easeOutBounce…
seems amazing these numbers, gonna rock !!