Permalink
Browse files

prototype: Simplify the NWMatcher adapter and optimize it for browser…

…s that don't need to extend DOM elements. [jddalton]
  • Loading branch information...
1 parent ece6e0e commit 2f9bde3ad5a2e3dd104c812b6c81f4077fe0aa1e @jdalton jdalton committed with kangax Apr 6, 2010
Showing with 6 additions and 2 deletions.
  1. +6 −2 vendor/nwmatcher/selector_engine.js
@@ -2,8 +2,12 @@ Prototype._original_property = window.NW;
//= require "repository/src/nwmatcher"
Prototype.Selector = (function(engine) {
- function select(selector, scope) {
- return engine.select(selector, scope || document, Element.extend);
+ var select = engine.select;
+
+ if (Element.extend !== Prototype.K) {
+ select = function select(selector, scope) {
+ return engine.select(selector, scope, Element.extend);
+ };
}
return {

12 comments on commit 2f9bde3

Contributor

gf3 replied Apr 6, 2010

Speed++

Nice :) Maybe give the Sizzle adapter the same treatment?

Collaborator

tobie replied Apr 6, 2010

Yes. I believe this should be at a higher level if any.

Collaborator

savetheclocktower replied Apr 6, 2010

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.

Collaborator

kangax replied Apr 6, 2010

John said it's about 10%, so I think it makes sense to have it.

Collaborator

savetheclocktower replied Apr 6, 2010

I trust him. But I still want to see the numbers. :-)

Collaborator

tobie replied Apr 7, 2010

@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.

Contributor

gf3 replied Apr 7, 2010

@tobie: Although, I must say, the public transparency is nice; for the rest of us.

Collaborator

tobie replied Apr 7, 2010

@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.

Collaborator

kangax replied Apr 7, 2010

@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.

Collaborator

tobie replied Apr 7, 2010

Woohoo! Meta bike-shedding.

Please sign in to comment.