Fix Windows resolution problems by replacing Data.Time.Clock.POSIX with System.Clock about criterion HOT 7 CLOSED

I'm using Windows 7 64-bit. With this patch I see a similar improvement.

from criterion.

What's the status of this? Is unpatched criterion good for benchmarking on Windows by now?

from criterion.

Thanks, I've fixed this in 53d3203.

The fix is fairly involved because it needs to work on multiple platforms. I particularly commend you to read the comment at the start of the Windows file.

from criterion.

Thanks for the update. I'll use criterion within Windows more often, and see how this improves time measurements. It looks like the clock library does things similarly.

At first I thought calling QueryPerformanceFrequency once at the start of testing was the wrong way to go about it. I seem to remember a Microsoft example that called it once before every pair of calls to QueryPerformanceCounter, which indicated to me the performance counter's frequency was not stable.

According to a comment on QueryPerformanceFrequency, the behavior is affected by which timing hardware is available to Windows. Perhaps modern computers all have a stable "TimeStampCounter".

from criterion.

I still see this bug with criterion-0.8.0.1. Is the patch not yet in the latest released version?

from criterion.

There is not a release that has this fix. You'll want to use HEAD for a bit if you need it.

from criterion.

Ok, thanks.

from criterion.