This comment was originally written by @tatumizer

I, of course, meant only internal changes inside Stopwatch implementation, not API changes.

This is a VM only problem (since dart2js obviously uses doubles already).

Is this still a problem when your code gets optimized, or is it just the first initial calls to stopwatch that are slow?
(Pro-top: Always run your benchmarks until the code is warm before doing the real measurement - unless what you are measuring is start-up time).

Removed Type-Defect label.
Added Type-Enhancement, Area-Library, Library-Core, Triaged labels.

This comment was originally written by @tatumizer

This is part of a set of benchmarks where I always use 3 warmups, but results show only first warmup makes sense. Please run on WIndows (32 bit). WIth 64-bit, this won't be a problem.
 
var N=10000000;
test4() {
  int x=0;
  var w=new Stopwatch()..start();
  for (int i=0; i<N; i++) {
    var n=w.elapsedMilliseconds;
    x|=(n&0xFF);
  }
  return x;
}
main() {
  test4(); // warmup
  w = new Stopwatch()..start();
  print("${test4()} ${w.elapsedMicroseconds}");

}

cc @fsc8000.

This comment was originally written by @tatumizer

More accurate data: 2.7 GHz processor i7, with all SIMD instructions imaginable:
elapsedMicroseconds - 285 nanoseconds per invocation of getter
elapsedTicks - 82 nanoseconds per invocation of getter

Neither is good.

Fwiw, I just ran this on my machine, and if I read the data correctly, it's now much faster.
Running the program on my machine takes 556413 (desktop) or 605918 (notebook) microseconds, which means that the elapsedMilliseconds getter took ~60 nanoseconds.

This was tested on my desktop (Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz) and my notebook (Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz).

elapsedTicks is ~10% faster.

From my last measurements it looks like elapsedMilliseconds has acceptable performance now.