Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
prototype: Simplify the NWMatcher adapter and optimize it for browser…
…s that don't need to extend DOM elements. [jddalton]
- Loading branch information
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speed++
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :) Maybe give the Sizzle adapter the same treatment?
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I believe this should be at a higher level if any.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any actual numbers that show how much faster this approach is? If it reflects, say, a 10% speed increase, I'd be happy to see this moved from the adapter itself into our own code. If it's more like a 3% increase, I say it's not worth the bother.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
John said it's about 10%, so I think it makes sense to have it.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I trust him. But I still want to see the numbers. :-)
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Between 0 and 10%
Benchmarks: http://www.fusejs.com/prototypejs/speed/index.php?css=yahoo
Firefox 3.6.2 firebug
Firefox 3.6.2 no-firebug
Safari 4.0.4
IE8
Opera 9.64
Chrome 4.x
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kangax: in the future, would appreciate if we discussed this within core before committing. Improving performance is essentially about improving bottlenecks. For selector engines, the bottle neck is in IE, not elsewhere.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tobie: Although, I must say, the public transparency is nice; for the rest of us.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gf3: Yeah. Good point. For the record. I'm totally in favor of moving all of our internal discussions to public, read-only (I dislike bike-shedding more than opacity) mailing lists.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tobie
It's a 3-line snippet of clean, easy-to-understand code that gives up to 10% boost. And packaged in a nice, ready-to-apply patch. I'm all for improving bottlenecks, but frankly don't see what the problem is in this case :)
As far as public discussion... Of course I'd love to see that too. But I don't agree with making it read-only. There must be other ways to prevent bike-shedding other than disallow input from the public side. For example, there are often fruitful discussions on WHATWG and es-discuss mailing lists, including non-commitee members pointing out flaws or providing better alternatives.
2f9bde3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woohoo! Meta bike-shedding.