Some people got it seriously, some people were complaining about the original test saying that the TaskSpeed util is not really representative case affected by css-selecters and stuff.
So I sat down and had written my own simple test, you can get it over here. This test eliminates any unnecessary disturbances, like elements selection, gets the questionable elements building process to the minimum and creates clean, pure functionality one-on-one performance test results.
The result is predictable and actually correlates pretty closely with the original TaskSpeed based benchmarks.
Google Chrome
Firefox 3.5.6
Opera 10.10
As you can see, in a blunt, face to face performance test, RightJS does murk jQuery several times.
Get use to it.
UPD: As I'm working on the test suite, I've added the pure-dom test and also publishing results for Opera.
11 comments:
Hi
Sorry to say, but at least one of your tests still suffers from a non apples to apples problem. Specifically the "make" tests. The jquery make test does parsing of strings into dom elements and various appends. The rightjs make test is just a wrapper for DOM creation. That's not even close to the same thing.
Hi Sheldon,
Probably, but don't blame me, I just test how jQuery actually builds elements, because people do build elements this way from time to time.
But don't count it if you don't like the idea, it's just one test among many others and not the slowest one. So it won't change anything.
Hello Nikolay,
Let me know are you have this for IE 6 & 7 & 8?
@Mostafa
On the official site there are benchmarks for IE, Opera, etc.
http://rightjs.org/benchmarks
Is there some reason for find using setidN instead of #setidN?
It has no effect on the RightJS times but drops the jQuery times to single digits.
@ Matthew
I'm not a big specialist in jQuery and took this command from the original TaskSpeed test for jQuery.
But thanks for pointing me to the issue, the times difference looked weird to me too. Will change it in a minute.
Matthew
huh, you were right! now the results are more consistent. Thanks for the tip!
No problem.
Also, if you're going to list percent change (which is what the table implies to me), the formula is ((x - y) / y), not (x / y).
So, if RightJS took 102ms and jQuery took 755ms, the change is 640%, not 740%. (Yes, 755ms is 740% of 102ms, but the change is 640%.)
Good point, but I think it's better to get out of the percents and diffs at all, so it was more clear, like if we have 10 and 20, it was saying something like "2x", which sounds easier to grasp to me than "+100%"
That's a really good update Nikolay, seems much closer to what I would expect the differences to be.
Out of interst, related to the fix, has the selector engine for rightjs got a special syntax for other things besides id's?
@Sheldon
RightJS supports all the standard CSS3 selectors, it mostly uses the native querySelector feature, and mocks it with some simple manual selectors engine for the old browsers.
I did also tried to write a test for them, but as both RightJS and Sizzle use the same native feature, it was pointless and results were about the same.
Post a Comment