On 19 September 2012 12:38, Peter Alexander <peter.alexander...@gmail.com>wrote:
> 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. > So then we need to start getting tricky, and choose the slowest one that is not beyond an order of magnitude or so outside the average?