Correct me if I am wrong, but I don't think selection by an ID is anywhere near a bottleneck for web pages or web apps. Do you have some benchmarks showing it's slow?

So that's how you handle a contribution. By assuming i'm stupid and have cached the actual dom output. You obviously haven't looked at a single line of my changes otherwise you would;ve made a slightly smarter reply i suppose.

.1 Optimizing is _NEVER_ bad. Curently the jquery performance of selecting a dome element is ~10x slower the doing it "manually" with getElementById() so it certainly can use a improvement.

.2 So the jsperf isn't a benchmark good enough for you. Please...

.3 Since you didn't read the code. I will spell it out for you. I am caching the output of the match variable and am using that when the selector is given a second time. Then i'm still using getElementById so no dom caching!

Sorry for nitpicking heavily on you right now, but your reply made my slighty on edge.

I know i haven't provided a diff. I have provided the sources (you can see it in the jsperf or directly here: http://www.sc2.nl/js/jquery-2.0.0_custom.js) Making a diff is trival, but i just didn't do it yet.

Optimizing is _NEVER_ bad.

Optimizing for what? Size? Speed? Code complexity?

The current code can get 1.5 MILLION IDs per second. How is that slow? Why should we further optimize the case that is already fast?

Replying to [comment:3 dmethvin]:

> Optimizing is _NEVER_ bad. Optimizing for what? Size? Speed? Code complexity? The current code can get 1.5 MILLION IDs per second. How is that slow? Why should we further optimize the case that is already fast?

1.5 million is very fast indeed. Yet native is 10x faster. I just don't think that jquery should add such a big load on javascript. It would be kinda pointless for browser vendors to further optimize javascript if they would follow your reasoning.

In my opinion jQuery should stay close to native javascript and do everything to get there. My patch brings the id selection to ~1/5th native performance and i would like to get at 9/10th (near native) with jQuery.

By your logic, if you want to get from New York to California faster, you should run to your garage before driving there because clearly running is faster than walking. True, but it doesn't make any real difference to the overall time it takes to get across the country.

You're not optimizing anything useful. Run a profiler on a real web page and see what is really taking the time. It isn't at all bottlenecked on getting elements by ID. Don't let jsperf fool you into thinking that you've increased performance by 3x in any real sense.

Nice, i certainly will think twice (or three times in this case) before ever submitting anything to jquery again. Guess performance is not important here.

Sorry it didn't work out. You might turn it into a plugin, in case someone out there needs to select more than 1 million unique IDs per second on a single page and jQuery is too slow to do it.

Oke, i've got a very nice additional performance improvement but i don't know why that is happening or if it's good by any means.

In jquery you have the lines:

jQuery = function( selector, context ) {

The jQuery object is actually just the init constructor 'enhanced'

return new jQuery.fn.init( selector, context, rootjQuery );

},

Now if i omit the "new" thus i get:

jQuery = function( selector, context ) {

The jQuery object is actually just the init constructor 'enhanced'

return jQuery.fn.init( selector, context, rootjQuery );

},

then the performance of the selector is shooting up! It is in fact at ~1/2 of native performance. So a quite significant improvement if you ask me. However, i wonder why this happens. Can i safely omit the "new"? And what is happening internally if i do so?

You can test it out here: http://jsperf.com/jquery-dom-selector-benchmark/2 (the "raw speed" tests)