If you're measuring throughput, it's better to disable GCProfiler, so
that the output will include error bounds (which can vary
substantially). On JDK8, I can only partially reproduce your results:
when asking for the tenth header in a list, `index` is 3-4% faster
than `iterator`:
Benchmark Mode Cnt Score
Error Units
MyBenchmark.index thrpt 10 10493.330 ±
123.896 ops/ms
MyBenchmark.iterator thrpt 10 10043.012 ±
69.775 ops/ms
MyBenchmark.iteratorWithoutScalarReplacement thrpt 10 8309.927 ±
25.661 ops/ms
However, keep in mind that I didn't design this benchmark to
accurately measure relative *throughput* with realistic header groups;
I wrote the benchmark to test the following perf claim (from
HeaderGroup.java):
// HTTPCORE-361 : we don't use the for-each syntax, when iterating headers
// as that creates an Iterator that needs to be garbage-collected
So far, every benchmark has demonstrated the opposite, that the
Iterator is optimized out completely and creates zero GC pressure. To
the extent that we are seeing throughput differences between the two
implementations, I suspect that it has something to do with the
concurrent modification checks in ArrayList's Iterator implementation;
whether this trade-off is worthwhile is a separate discussion.
If you still feel really strongly about avoiding for-each syntax (at
least with indexed collections), that's fine, but the above comment
should at least be updated to reflect the benchmark data.
On Wed, Nov 28, 2018 at 2:30 AM Oleg Kalnichevski <[email protected]> wrote:
>
> Can we move on now?
>
> ---
> Benchmark Mode Cnt Score Error
> Units
> Testing6.index thrpt 97019963.567
> ops/s
> Testing6.index:·gc.alloc.rate thrpt ≈ 10⁻⁵
> MB/sec
> Testing6.index:·gc.alloc.rate.norm thrpt ≈ 10⁻⁷
> B/op
> Testing6.index:·gc.count thrpt ≈ 0
> counts
> Testing6.iterator thrpt 80554752.864
> ops/s
> Testing6.iterator:·gc.alloc.rate thrpt ≈ 10⁻⁵
> MB/sec
> Testing6.iterator:·gc.alloc.rate.norm thrpt ≈ 10⁻⁷
> B/op
> Testing6.iterator:·gc.count thrpt ≈ 0
> counts
> ---
> Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
