<div class="gmail_quote">On 19 September 2012 12:38, Peter Alexander <span dir="ltr"><<a href="mailto:peter.alexander.au@gmail.com" target="_blank">peter.alexander.au@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The fastest execution time is rarely useful to me, I'm almost always much<br>
more interested in the slowest execution time.<br>
In realtime software, the slowest time is often the only important factor,<br>
everything must be designed to tolerate this possibility.<br>
I can also imagine other situations where multiple workloads are competing<br>
for time, the average time may be more useful in that case.<br>
</blockquote>
<br></div>
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.<br>

</blockquote></div><br><div>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?</div>