Comments on: Sizzle and MooTools by the Numbers http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/ Making stuff work on the other side of the request. Tue, 05 Jan 2010 18:16:32 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Chris http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32022 Chris Tue, 17 Feb 2009 06:39:28 +0000 http://www.clientcide.com/?p=796#comment-32022 The fact that the tests run _many_ iterations is because normal DOM query usage isn't enough to notice a difference in speed. I especially liked gonchuki's comments here: 'when was the last time you ran 43 queries in a row? let me answer fast: NEVER, unless you are Doing it Wrong.' The fact that the tests run _many_ iterations is because normal DOM query usage isn’t enough to notice a difference in speed. I especially liked gonchuki’s comments here:

‘when was the last time you ran 43 queries in a row? let me answer fast: NEVER, unless you are Doing it Wrong.’

]]> By: David Rivers http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32017 David Rivers Sat, 14 Feb 2009 09:11:52 +0000 http://www.clientcide.com/?p=796#comment-32017 @gonchuki Hey, I'm all about disenfranchising noobs and their archaic machinery. I'm just not sure it's commercially smart to just say the hell with them. I have many less-than-savvy friends with clunky, 5-10 yo Dells that run some kind of MSIE. I agree that these folk are accustomed to dealing with shit for load times. But, these are also consumers with checkbooks, and I reckon they'd be more likely to return to your site if it actually performs better than the other slow sites they've been to! Of course, if you have the analytics to prove that that's not your target, then by all means to hell with them!! @gonchuki Hey, I’m all about disenfranchising noobs and their archaic machinery. I’m just not sure it’s commercially smart to just say the hell with them. I have many less-than-savvy friends with clunky, 5-10 yo Dells that run some kind of MSIE. I agree that these folk are accustomed to dealing with shit for load times. But, these are also consumers with checkbooks, and I reckon they’d be more likely to return to your site if it actually performs better than the other slow sites they’ve been to! Of course, if you have the analytics to prove that that’s not your target, then by all means to hell with them!!

]]> By: gonchuki http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32009 gonchuki Fri, 13 Feb 2009 12:05:27 +0000 http://www.clientcide.com/?p=796#comment-32009 @David: in fact if you think about it, there are little specific cases in which those kind of users exist: locked corporations by an asinine IT department, poor people without much computer knowledge (which you won't be selling a product to them anyways), and Your Mom®. Facebook even took the initiative, and knowing that their site won't work at a good speed on a combo of IE6 + old computer they give you a nice notice to encourage upgrading. @Tim: it does work today, and Safari on the iPhone and Opera in the rest of handheld devices today can easily handle anything out there. I guess it would be nice to run the slickspeed test on those devices too. I don't know however about Windows Mobile, but as the desktop IE counterpart shown, difference between pure engines is so low in the worst case that the users cannot notice the difference. (specially on handheld, where 3G network lag eats away most of the "waiting time") @David:
in fact if you think about it, there are little specific cases in which those kind of users exist: locked corporations by an asinine IT department, poor people without much computer knowledge (which you won’t be selling a product to them anyways), and Your Mom®. Facebook even took the initiative, and knowing that their site won’t work at a good speed on a combo of IE6 + old computer they give you a nice notice to encourage upgrading.

@Tim:
it does work today, and Safari on the iPhone and Opera in the rest of handheld devices today can easily handle anything out there. I guess it would be nice to run the slickspeed test on those devices too. I don’t know however about Windows Mobile, but as the desktop IE counterpart shown, difference between pure engines is so low in the worst case that the users cannot notice the difference. (specially on handheld, where 3G network lag eats away most of the “waiting time”)

]]> By: Tim Lund http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32008 Tim Lund Fri, 13 Feb 2009 10:24:02 +0000 http://www.clientcide.com/?p=796#comment-32008 @gonchuki You're forgetting that Javascript some day has to work on handheld devices etc. Other than that, it's always good to look at the numbers your code is producing, and optimising it. These days of "hardware is cheaper than developers" must be taken with moderation. @gonchuki

You’re forgetting that Javascript some day has to work on handheld devices etc.

Other than that, it’s always good to look at the numbers your code is producing, and optimising it. These days of “hardware is cheaper than developers” must be taken with moderation.

]]> By: David Rivers http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32007 David Rivers Fri, 13 Feb 2009 09:24:44 +0000 http://www.clientcide.com/?p=796#comment-32007 @gonchuki Isn't that a catch-22, that IE6/8-yo computer users aren't the target demographic for a JS-heavy site? If JavaScript were to perform better in those cases, then it would be that much more appropriate to use it with that demographic! I definitely agree, however, that these tests would be much more scientific if all factors concerned (computer architecture, test page markup, and sample size) were as statistically significant as possible. Testing a single page with one machine (and only once? or few times) only tells you how to optimize for that one page for that one machine! @gonchuki Isn’t that a catch-22, that IE6/8-yo computer users aren’t the target demographic for a JS-heavy site? If JavaScript were to perform better in those cases, then it would be that much more appropriate to use it with that demographic!

I definitely agree, however, that these tests would be much more scientific if all factors concerned (computer architecture, test page markup, and sample size) were as statistically significant as possible. Testing a single page with one machine (and only once? or few times) only tells you how to optimize for that one page for that one machine!

]]> By: fabio m. costa http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32006 fabio m. costa Fri, 13 Feb 2009 07:43:49 +0000 http://www.clientcide.com/?p=796#comment-32006 @gonchiki: Loved your comments. @gonchiki:
Loved your comments.

]]> By: gonchuki http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32004 gonchuki Fri, 13 Feb 2009 05:23:59 +0000 http://www.clientcide.com/?p=796#comment-32004 <a href="http://sandbox.gonchuki.com/slickspeed_amd_600.jpg" rel="nofollow">as promised, test results on AMD Duron @ 600mhz</a> (from top to bottom: Firefox 3, IE6, Opera 9.6) what this means: The worst case scenario (IE6) for the pure selector engines leave Sizzle at a dismal advantage of 240ms over god-knows-how-many-iterations. As for decent browsers, they ace the test and even on this underpowered machine everything runs quite fast. Now, I'm not really good at demographics, but I'm pretty sure that people using both an 8 year old PC and IE6 are not the average target audience of a site heavily loaded on javascript. as promised, test results on AMD Duron @ 600mhz
(from top to bottom: Firefox 3, IE6, Opera 9.6)

what this means: The worst case scenario (IE6) for the pure selector engines leave Sizzle at a dismal advantage of 240ms over god-knows-how-many-iterations.
As for decent browsers, they ace the test and even on this underpowered machine everything runs quite fast.

Now, I’m not really good at demographics, but I’m pretty sure that people using both an 8 year old PC and IE6 are not the average target audience of a site heavily loaded on javascript.

]]> By: gonchuki http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32003 gonchuki Fri, 13 Feb 2009 00:43:14 +0000 http://www.clientcide.com/?p=796#comment-32003 just a thought, but have you tried extending slickspeed to run the test on a bigger sample of pages so the test is really done on REAL stuff? Either running on the default slickspeed page or the Yahoo homepage, will only get the results for these two pages. And this is specially a point for Sizzle as they are ultimately building a selector engine that benchmarks like crazy in the Yahoo homepage and nothing else. And don't forget to compare the results in either AMD and Intel architectures, and even on older Pentium 4 based processors, as that's where the performance difference would be noticeable. My 2 years old 2.7ghz AMD X2 runs the whole "single pass" slickspeed in 176ms in FF3 for both engines. Read that? a puny 176ms!!! for what, let me see... 43 queries! when was the last time you ran 43 queries in a row? let me answer fast: NEVER, unless you are Doing it Wrong. IE6 even came faster at 122ms for Sizzle and 112 ms for Moo (posibly the result of having 20+ extensions enabled at this time, or that IE6 is running native in my WinXP as I never cared to do the upgrade to IE7 in this machine) Given those numbers, is it really important? is there a need to squeeze yet another millisecond today, knowing that CPUs are getting faster every day? does even a relatively high 250ms mean anything when the page may take several seconds to load due to any other factor like file transfer, DOM parsing or even network lag on each request? Should we really care for users on ancient computers using ancient browsers? aren't they used to get everything slow in the net? if they can't run a moderately complex flash game with ease, then they are already expecting everything to be slow. To day, the slowest CPU I consider in my tests is an Atom, if it runs decently on it, then consider it gold. FWIW, I will run the updated suite on my secondary machine which is an AMD Duron @ 600mhz from around 2001 and post here the results. I already tried it on FF3 and the results will puzzle every contender for the biggest selector engine e-penis out there. just a thought, but have you tried extending slickspeed to run the test on a bigger sample of pages so the test is really done on REAL stuff?
Either running on the default slickspeed page or the Yahoo homepage, will only get the results for these two pages. And this is specially a point for Sizzle as they are ultimately building a selector engine that benchmarks like crazy in the Yahoo homepage and nothing else.

And don’t forget to compare the results in either AMD and Intel architectures, and even on older Pentium 4 based processors, as that’s where the performance difference would be noticeable. My 2 years old 2.7ghz AMD X2 runs the whole “single pass” slickspeed in 176ms in FF3 for both engines. Read that? a puny 176ms!!! for what, let me see… 43 queries! when was the last time you ran 43 queries in a row? let me answer fast: NEVER, unless you are Doing it Wrong. IE6 even came faster at 122ms for Sizzle and 112 ms for Moo (posibly the result of having 20+ extensions enabled at this time, or that IE6 is running native in my WinXP as I never cared to do the upgrade to IE7 in this machine)

Given those numbers, is it really important? is there a need to squeeze yet another millisecond today, knowing that CPUs are getting faster every day? does even a relatively high 250ms mean anything when the page may take several seconds to load due to any other factor like file transfer, DOM parsing or even network lag on each request?

Should we really care for users on ancient computers using ancient browsers? aren’t they used to get everything slow in the net? if they can’t run a moderately complex flash game with ease, then they are already expecting everything to be slow. To day, the slowest CPU I consider in my tests is an Atom, if it runs decently on it, then consider it gold.

FWIW, I will run the updated suite on my secondary machine which is an AMD Duron @ 600mhz from around 2001 and post here the results. I already tried it on FF3 and the results will puzzle every contender for the biggest selector engine e-penis out there.

]]> By: Rey Bango http://www.clientcide.com/3rd-party-libraries/sizzle-and-mootools-by-the-numbers/comment-page-1/#comment-32000 Rey Bango Thu, 12 Feb 2009 23:50:20 +0000 http://www.clientcide.com/?p=796#comment-32000 To clarify my position on selectors, I do think we're reaching a point where improvements in traversal performance will yield negligible results but that doesn't mean that we'll stop looking at tweaking things. The increased demands of JS applications will continue to push the demands of the language and frameworks so, as Aaron said, we really need to look at the whole framework and see how all pieces can be optimized to improve application performance. To clarify my position on selectors, I do think we’re reaching a point where improvements in traversal performance will yield negligible results but that doesn’t mean that we’ll stop looking at tweaking things. The increased demands of JS applications will continue to push the demands of the language and frameworks so, as Aaron said, we really need to look at the whole framework and see how all pieces can be optimized to improve application performance.

]]>