I looked into this a bit more, and it turns out that "how many
operations got executed within the same given period of time" is *not*
what you are measuring. Based on your JMH output, you are running in
SampleTime mode [1]:
/*
* Mode.SampleTime samples the execution time. With this mode, we are
* still running the method in a time-bound iteration, but instead of
* measuring the total time, we measure the time spent in *some* of
* the benchmark method calls.
*
* This allows us to infer the distributions, percentiles, etc.
*
* JMH also tries to auto-adjust sampling frequency: if the method
* is long enough, you will end up capturing all the samples.
*/
So the numbers you are quoting are the number of samples taken of each
benchmark, not the total number of invocations. (To measure total
throughput, you would use Mode.Throughput or Mode.SampleTime.) This is
why the average benchmark runtime is statistically identical (48 vs 49
nanoseconds/op), despite the sample counts being so different.
[1]
http://hg.openjdk.java.net/code-tools/jmh/file/66fb723292d4/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_02_BenchmarkModes.java
On Tue, Nov 27, 2018 at 1:45 PM Oleg Kalnichevski <[email protected]> wrote:
>
> To me those are the only meaningful numbers - how many operations got
> executed within the same given period of time.
>
> More importantly, however, can we concentrate on something a bit more
> useful than applying pointless syntactic sugar, finalizing the APIs,
> for instance?
>
> Oleg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
