Comment 5 for bug 1072379

Thanks for the suggestion. The current implementation creates a
stopwatch for each test, so use of the static method might be better
anyway.

Charlie

On Thu, Nov 15, 2012 at 2:53 AM, Geoffroy Querol
<email address hidden> wrote:
> Hello everyone,
>
>
> Just a few notes on the current stopwatch implementation of microsoft, it has a few issues on multicore systems :
> (noted in the reference page http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx)
>
> in short 1): if the stopwatch instance is used on a thread for which the
> processor affinity is not set to a single logical core, the stopwatch
> measurements are unreliable (they will report negative times,
> unbelieavable times like 100 times the amount).
>
> 2) from my personal experience with this class, i tried to work arround
> this (setting processor afinity is clearly what you dont want to deal
> with) using the StopWatch.GetTimeStamp() method which is supposed give a
> high resolution timer if the underlying system supports it. this amount
> of ticks can be converted into ms like that:
>
> var start = StopWatch.GetTimeStamp();
> var end = StopWatch.GetTimeStamp();
> long elapsedms = ((end - start) / StopWatch.Frequency;
>
> On the plus side, this static method might be lighter and lower level
> than the instance usage.
>
>
> Btw, thanks for your hard work.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1072379
>
> Title:
> Report test execution time at a higher resolution
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nunit-3.0/+bug/1072379/+subscriptions