Review of Andrei's std.benchmark
Peter Alexander
peter.alexander.au at gmail.com
Wed Sep 19 02:38:27 PDT 2012
> The fastest execution time is rarely useful to me, I'm almost
> always much
> more interested in the slowest execution time.
> In realtime software, the slowest time is often the only
> important factor,
> everything must be designed to tolerate this possibility.
> I can also imagine other situations where multiple workloads
> are competing
> for time, the average time may be more useful in that case.
The problem with slowest is that you end up with the occasional
OS hiccup or GC collection which throws the entire benchmark off.
I see your point, but unless you can prevent the OS from
interrupting, the time would be meaningless.
More information about the Digitalmars-d
mailing list