JavaScript function for getElementById

[adam]

I didn't quite read all the responses on here as I've only got so much time for my lunch, but I was quite intrigued by this. Just to throw a spanner in the works I did some tests to find out exactly what the difference would be...

Normal method: time taken for 100,000 calls averaged around .6 milliseconds
Wrapped method: time taken for 100,000 calls averaged around .4 milliseconds

... Go figure?

[deathshadow]

(Jan-13-2010 02:19 PM)adam Wrote:  Just to throw a spanner in the works I did some tests to find out exactly what the difference would be...

What browser? What are you using as the timer (remember FF's timer cannot be trusted for such short durations), which one are you calling 'wrapped' and which one are you calling 'normal'?

In the majority of cases the system timer available to most browsers has a 16ms accuracy, except that IE takes 10ms longer to react to a timer message. This is why a better approach for javascript benchmarking is to simply have your routine run flat out incrementing a counter, only stopping when a variable changes - then setting a timeout of say... one to two seconds to see how many iterations run.

It is possible for the wrapped function to run faster in SOME browsers where there's something called 'function cache' where self-contained functions calling the same routine when the DOM is unchanged have their results cached like they were a variable and not a function - problem is that it makes the page take longer to load when those types of wrappings are set up, and it doesn't work when the browser is already chewing on RAM from something like having multiple tabs open - it's one of those optimization trade-offs... But if you are going to have that type of optimization, why would the user function have it but the system function not? (that's bad engine optimization... I smell Firefox)

Care to share the code you are using to test and details on your testing method?

[adam]

I actually made some minor mistakes with the time formatting of my last tests.

I've re-worked it now and the results are:

Normal (document.getElementById()) method: ~600-700 milliseconds for 100,000 calls (FF3.5)
Wrapped (getElement()) method: ~400 milliseconds for 100,000 calls (FF3.5)

I did think the previous times sounded way too quick; though these do actually reflect similarly to my previous results, just correctly measured. I'm calculating the time taken by comparing the milliseconds before and after the calls since the Unix epoch. The 'call' being; repetitively running (not through a loop) either:

Code:

var test = document.getElementById('mydiv');
// or
var test = getElement('mydiv');

With getElement() simply returning the document.getElementById(..). Used PHP to spit out the 100,000 calls. Performed all tests with the browser being the only app running with just that tab (and notepad).

I think you may be right with the "function cache" though, results from other browsers:

IE6

Normal ~1,800ms
Wrapped ~2,300ms

Little change each time run.

Opera 10

Normal ~120ms
Wrapped ~170ms

Very little change.

Safari 4

First run:

Normal 127ms
Wrapped 547ms

Average after that:

Normal ~120ms
Wrapped ~70ms


----

Not really sure what these show anymore, guess it all varies on the function caching for the browser. Opera definitely looking like the best all-round average browser to use, should you want to ever run 100,000 calls to document.getElementById!

Ha, invested a little too much time into this now..

[deathshadow]

Those numbers didn't sound right to me - so I wrote up my own test:

http://www.cutcodedown.com/for_others/lo...ement.html

I use date.gettime which has some accuracy issues, but because we're running tight loops trying to use settimeout (I just discovered) sends FF off to never-never land. 2.4 seconds being an even multiple of 16ms and pausing until the timer ticks-over should eliminate most of those issues though. Instead of hard looping which has the habit of making FF report 'not responding' and to eliminate any other issues, I track how many iterations can be done over a fixed period of time (2.4 seconds) and set up 3,072 different elements to run 'get' on so we figure deep nesting performance and DOM optimization into it too. I do three get's for each 'count' so as to replicate more complex structure handling.

My results here were interesting. In FF, I was getting results where MOST of the time calling document.getElementById was 15-18% faster than wrapping it in a function, but every once and a while it returned with the 'get' function being 2-3% faster. It makes me question if it's even possible to clean benchmark this as 15-18% is WAY too much skew for just a function call wrapper, while it makes little to no sense for the function version to EVER be faster.

Testing in other browsers Opera appears to handle the iterations twice as fast as FF (big shock) returning around 330K to FF's 160K, however the unwrapped version is ALWAYS 2-3% faster. These numbers are closer to what I expected to see.

With Safari and Chrome something 'wierd' is going on, as Chrome is coming in 50% faster than Opera, but Safari is coming in three times faster than Chrome... I'm wondering if that chrome sandbox is costing the engine performance. In Safari unwrapped wins about 4 out of every five itereations by 3-4%, but every once and a while an oddball occurrence of wrapped winning crops up... Chrome sees similar variance, though it's 50/50 on win/lose, though the range of win/lose (-1% to +4%) is the same. I suspect that the getTime method simply lacks the accuracy for this type of benchmarking. I also suspect that this flip-flop variance and execution time being so close is from Google's emphasis on running even their own crappy javascript just as fast as if it was written properly. You know, don't fix the code, optimize the engine it's running on instead... (shades of Java)

IE is where the real fun is. In IE7 and 8 the non-function wrapped version wins hands down every time, but I found something wierd when I went to IE6. In identical VM's of XP, one with 7 and one with 6, IE6 was consistently 50% faster than IE7 running this test. Even stranger, the function wrapped version won by 0.5% consistently 4 out of five times - but as per safari/chrome when the numbers were reversed, the non-wrapped won by 3-4%.

I'm going to play with this more - if you folks feel like reporting some numbers feel free, you can click on the test to restart it, part of why I used so many nested elements is it appears to blow out FF's element and function cache, so the results on a refresh or just re-running shouldn't have as much skew, though in FF the longer you retry the test without hitting refresh the more often the 'oddball' result of function wrapped winning by 5-7% will crop up. (though after a refresh unwrapped wins by as much as 20%)

Oh, and don't move the mouse during testing, it destroys the results. You can actually skew the results by moving the mouse during whichever part of the test you want to lose

-- edit --

I made some more changes to it, increasing the time to 4800ms per test and upping the interval between tests to 320ms. The increase in time levels out the oddball results in firefox (longer times always make timer accuracy issues less of an issue) - I'd set it higher, but FF automatically treats and javascript that runs for more than five seconds as a 'rogue' process and will report it as 'not responding'.

After the changes, FF's numbers are comparable to opera - unwrapped always wins by 7-9%... gah, but it messed up chrome REALLY bad. What the? Chrome is reporting as the winner by my color coding code the opposite of what the result numbers say... Ah, got it, typecasting issue, it's retuning NAN on the compare.

-- edit --
even further changes, Chromes and Safari's numbers seemed all wrong, so I made it pull a random get out of 4096 'groups' (12,288 elements) which flattened out the results more. Quirks and 'cheating optimizations' in the various browsers always take a bit of fiddling to get around.

[deathshadow]

Woah, I just noticed something - the more iterations you let it run, the faster FF is... or is it the slower Opera is... Now that it's 4.8 seconds per test they're returning near identical numbers... you drop it to 2.4 seconds and Opera runs 50-80% faster than FF.

That's just wierd.

[carbonize]

You should test it in the new Opera JS engine, Carakan, coming in 10.5.

[adam]

Nice test app - much more thorough than mine. Your results do make more sense too. Shall definitely remember your method for any similar/related future benchmarking.

[carbonize]

I just ran DS's test page in portable versions of Chrome, Firefox 3.7 pre alpha and Opera 10.50 and Chromes results were in the 900s. Firefox 3.7 around the 500 mark with wrapped being faster (marginally) but Opera was only doing around 250 per ms which seems a tad wrong to me.

[cbuckley]

hmm that was actually extremely interesting. Thanks.