nunit-core team mailing list archive

[Geoffroy Querol <geoffroy.querol@xxxxxxxxx>]

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 a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/1072379

Title:
  Report test execution time at a higher resolution

Status in NUnit Test Framework:
  Triaged
Status in NUnitLite Testing Framework:
  Fix Committed
Status in NUnit V2 Test Framework:
  Triaged

Bug description:
  Currently, we measure test execution time using DateTime.Now, which
  depends on the System Timer. Per the docs, that gives us a resolution
  of 10ms, although it seems higher in practice, probably due to context
  switching time.

  Really, if we want a good measure of how long it took to run a test,
  we should probably be using the Stopwatch class.

  While we are at it, we should probably use a TimeSpan rather than a double to represent elapsed time in the TestResult class,
  at least in NUnit 3.0, and possibly in the other projects as well. The NUnit 2.6 XML should continue to report time in seconds, while the NUnit 3.0 XML can use a string representation of the TimeSpan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nunit-3.0/+bug/1072379/+subscriptions