On 25 Jan 2005 14:22:40 -0800, you wrote:
I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call.
This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...).
Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows?
Andreas Mohr
Our system uses the performance counter all the time in extremely time critical code. If the call is anything more than a few cycles with absolutely no chance of blocking, we are hosed!
The application is an embedded audio plugin player. The audio is processed with SCHED_FIFO and needs to be as deterministic and fast as possible.
I hope this fix/change doesn't jeopardize our product's use of Wine...
You are of course in an excellent position to quantify better then "extremely time critical" and "few cycles". Just try the patch and tell us when you are "hosed".
I have done a few further tests. A loop like:
for(i=0;i<10000000;i++) QueryPerformanceCounter( &count);
takes under Windows 2k, on some hardware 45 seconds. Under Wine on the exact same hardware it takes (with the patch) 13 seconds.
If you do a series of QueryPerformanceCounter:
QueryPerformanceCounter( carr[0]); QueryPerformanceCounter( carr[1]); QueryPerformanceCounter( carr[2]); QueryPerformanceCounter( carr[3]); QueryPerformanceCounter( carr[4]); ...
and print the results, I see on Windows that the counter increments 4 or 5 steps between the calls. Under Wine it is 1 or 2.
So in these simple benchmarks, Wine beats Windows by a factor of three. I call that satisfactory, wishing Wine would do that in other areas as well.
Also note that QueryPerformanceCounter Timer takes hundreds of cycles. In an extremely time critical application that would be hosed if it takes more then a few cycles, I would not recommend the use of this call at all.
Rein.