Performance/Status Meetings/2007-June-06: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
Line 35: Line 35:
* Getting higher resolution timers for tests
* Getting higher resolution timers for tests
** '''AI:Damon''' will meet with Boris about this. Different issues on different platforms.
** '''AI:Damon''' will meet with Boris about this. Different issues on different platforms.
== AI:Damon:  Timer Resolution ==
Information from Boris: 
There are several timers that are involved in the performance tests.  First of all, there is the JS Date.now() function.  This is a priori accurate to no better than 1ms.  We also use JS timeouts (same accuracy) and perl's timing stuff (worse, unless Time::HiRes is installed, which it should be on all the test boxen; with HiRes we should be getting microsecond precision).
In practice, the actual accuracy is sometimes worse than the 1ms accuracy listed above.
On Windows some of the commonly-used timer APIs (e.g. timeGetTime) only give 15ms accuracy; I'm not sure which, if any, of the above are affected by that.  I seem to recall issues with JS timeouts due to that.  Certainly anything on Windows that uses PR_IntervalNow() will be affected by the timeGetTime behavior.
Most of the other things above seem to use gettimeofday on Linux and GetSystemTimeAsFileTime on Windows; both seem to be accurate enough for our purposes.  I think. The msdn docs on GetSystemTimeAsFileTime are pretty slim.
On Mac I'm really not sure what the situation is.
In general, I _think_ that anything that's using JS Date.now() directly is good for 1ms precision (which means that tasks of under 100ms are hard to time to 1% accuracy).  Anything using timeouts (I seem to recall Tp does this?) will get noise in it due to PR_IntervalNow; on Windows this might be a lot of noise.  Ts uses the Perl timing, which should be ok.


== Other Information ==
== Other Information ==
Confirmed users
1,067

edits

Navigation menu