Confirmed users
1,067
edits
(→Agenda) |
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 == | ||