Timing in JavaScript and browsers can’t be trusted
Written by on Wednesday, November 12th, 2008 in Uncategorized.
This is officially the week of John. If he delivers top notch posts for the rest of the week he wins an Ajaxian award or something. Maybe we need to bring back the “pack of cards” where each card is an Ajax personality and John gets to be Ace of Hearts or something.
I remember talking with some of the V8 team about how poor the world of timing is. Chrome is a lot more accurate in its timing, which can do it a disservice in browser performance tests. Some browsers would respond with “0″ when Chrome would return “0.001″ and it would hence suffer.
Add that to the flawed “just add up the total time for all tests” mentality of some tests and you end up with very skewed results (you could do amazingly bad on one test that in practice never matters and really well on the others, but it all evens out).
Here comes John with a post on the accuracy of JavaScript timing which came out of a bad situation:
I was running some performance tests, on Internet Explorer, in the SlickSpeed selector test suite and noticed the result times drastically fluctuating. When trying to figure out if changes that you’ve made are beneficial, or not, it’s incredibly difficult to have the times constantly shifting by 15 - 60ms every page reload.
This lead him to tests life on various browsers and operating systems and he put up the raw data for you to check out.
He concludes:
Testing JavaScript performance on Windows XP and Vista is a crapshoot, at best. With the system times constantly being rounded down to the last queried time (each about 15ms apart) the quality of performance results is seriously compromised. Dramatically improved performance test suites are going to be needed in order to filter out these impurities, going forward.
Source: Ajaxian » Front Page
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/451488258/timing-in-javascript-and-browsers-cant-be-trusted








