I suppose that's possible, but there are several other modes available
that don't use sampling. If you're interested in throughput of heap
allocation, you can use Mode.Throughput with the GC profiler (partial
results shown):
Benchmark Mode Cnt
Score Error Units
MyBenchmark.index:·gc.alloc.rate.norm thrpt 3
176.000 ± 0.001 B/op
MyBenchmark.iterator:·gc.alloc.rate.norm thrpt 3
176.000 ± 0.001 B/op
The numbers for Mode.AverageTime are pretty much the same; I don't
think the two are different when using GCProfiler.
I also wrote a version of the benchmark that allows the Iterator
object to escape, thus defeating scalar replacement. This version does
perform more allocation, as expected:
Benchmark
Mode Cnt Score Error Units
MyBenchmark.index:·gc.alloc.rate.norm
thrpt 3 176.000 ± 0.001 B/op
MyBenchmark.iterator:·gc.alloc.rate.norm
thrpt 3 176.000 ± 0.001 B/op
MyBenchmark.iteratorWithoutScalarReplacement:·gc.alloc.rate.norm
thrpt 3 208.000 ± 0.001 B/op
I can also confirm that indexing performs worse than iterating when
using a HeaderGroup backed by a LinkedList (containing nine elements):
Benchmark Mode Cnt Score Error Units
MyBenchmark.index avgt 3 106.215 ± 1.261 ns/op
MyBenchmark.iterator avgt 3 78.689 ± 8.851 ns/op
MyBenchmark.iteratorWithoutScalarReplacement avgt 3 80.600 ± 5.045 ns/op
In other words, using an iterator (such as by way of a for-each loop)
can improve time efficiency (due to algorithmic efficiency), with no
effect on GC pressure (thanks to JIT optimizations). Just for grins, I
re-ran the LinkedList benchmark using -Xint (which forces the entire
JVM to run in interpreted mode) and observed a nearly two
order-of-magnitude performance degradation:
Benchmark Mode Cnt Score
Error Units
MyBenchmark.index avgt 3 5088.854 ±
844.754 ns/op
MyBenchmark.iterator avgt 3 4997.693 ±
583.512 ns/op
MyBenchmark.iteratorWithoutScalarReplacement avgt 3 4954.591 ±
361.937 ns/op
On Tue, Nov 27, 2018 at 4:00 PM Gary Gregory <[email protected]> wrote:
>
> Can the variations be explained by GC pauses and other processes using the
> CPU?
>
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
