You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Gary Gregory <ga...@gmail.com> on 2018/11/23 03:12:11 UTC
Enhanced for-loops
Hi All:
In the HC code base, we could avoid some boilerplate clutter by using
Java's enhanced for-loop construct. I believe this would make the code
easier to read. Are there any objections to making this change?
Gary
Re: Enhanced for-loops
Posted by Gary Gregory <ga...@gmail.com>.
On Sat, Nov 24, 2018 at 7:37 AM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2018-11-24 at 15:04 +0100, Michael Osipov wrote:
> > Am 2018-11-23 um 09:20 schrieb Oleg Kalnichevski:> On Thu, 2018-11-22
> > at
> > 20:12 -0700, Gary Gregory wrote:
> > >> Hi All:
> > >>
> > >> In the HC code base, we could avoid some boilerplate clutter by
> > using
> > >> Java's enhanced for-loop construct. I believe this would make the
> > >> code
> > >> easier to read. Are there any objections to making this change?
> > >>
> > >> Gary
> > >
> > > I am _strongly_ against it. Last time you did that it had caused
> > us a
> > > lot of grief.
> > >
> > > https://issues.apache.org/jira/browse/HTTPCORE-361
> > That's an interesting case because it is an antipattern to access
> > collections via index. The recommended way is to use iterators. Why
> > have
> > create the iterator directly and call next() once? Still to much
> > overhead?
> >
> > Michael
>
> This is what one unnecessary object allocation in a critical execution
> path can do to you.
>
> Strongly disagree about collection element access by index being an
> anti-pattern. Who invents this kind of stuff?
>
When you access a linked list by index (LinkedList is one example) without
random access, access for a single element is O(N), which is terrible when
you iterate through the whole array, O(N^2).
If your linked list provides random access (ArrayList in one example),
access for a single element is O(1), which is great when you iterate
through the whole array, O(N).
So, before you write a loop on any Collection that loops through all
elements, you better know which kind of collection you are dealing with...
Gary
Gary
>
> Oleg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2018-11-24 at 15:04 +0100, Michael Osipov wrote:
> Am 2018-11-23 um 09:20 schrieb Oleg Kalnichevski:> On Thu, 2018-11-22
> at
> 20:12 -0700, Gary Gregory wrote:
> >> Hi All:
> >>
> >> In the HC code base, we could avoid some boilerplate clutter by
> using
> >> Java's enhanced for-loop construct. I believe this would make the
> >> code
> >> easier to read. Are there any objections to making this change?
> >>
> >> Gary
> >
> > I am _strongly_ against it. Last time you did that it had caused
> us a
> > lot of grief.
> >
> > https://issues.apache.org/jira/browse/HTTPCORE-361
> That's an interesting case because it is an antipattern to access
> collections via index. The recommended way is to use iterators. Why
> have
> create the iterator directly and call next() once? Still to much
> overhead?
>
> Michael
This is what one unnecessary object allocation in a critical execution
path can do to you.
Strongly disagree about collection element access by index being an
anti-pattern. Who invents this kind of stuff?
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Michael Osipov <mi...@apache.org>.
Am 2018-11-23 um 09:20 schrieb Oleg Kalnichevski:> On Thu, 2018-11-22 at
20:12 -0700, Gary Gregory wrote:
>> Hi All:
>>
>> In the HC code base, we could avoid some boilerplate clutter by using
>> Java's enhanced for-loop construct. I believe this would make the
>> code
>> easier to read. Are there any objections to making this change?
>>
>> Gary
>
> I am _strongly_ against it. Last time you did that it had caused us a
> lot of grief.
>
> https://issues.apache.org/jira/browse/HTTPCORE-361
That's an interesting case because it is an antipattern to access
collections via index. The recommended way is to use iterators. Why have
create the iterator directly and call next() once? Still to much overhead?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2018-11-28 at 14:04 -0700, Gary Gregory wrote:
> Can we agree that using for-each for array[]s is OK?
Fine by me. My objection is to using for-each indiscriminately,
especially where the underlying collection type is known. We all are
old enough to be able to access ArrayList elements by index.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Gary Gregory <ga...@gmail.com>.
Can we agree that using for-each for array[]s is OK?
Gary
On Wed, Nov 28, 2018 at 11:55 AM Ryan Schmitt <rs...@apache.org> wrote:
> 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 <ol...@apache.org>
> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2018-11-28 at 10:55 -0800, Ryan Schmitt wrote:
...
> 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.
>
Feel free to remove those comments. I generally dislike and disapprove
references to JIRA tickets in the source code. This is what commit
messages are for, wherein they refer to a specific issue within a
particular context at a particular point of time.
I am also not again for-each constructs per se, as long as they are not
being used for no reason, for instance, to replace perfectly valid
indexed access to ArrayList elements in performance critical areas of
code.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
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 <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2018-11-27 at 16:52 -0800, Ryan Schmitt wrote:
> 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):
>
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
> 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 Er
> ror 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 <ga...@gmail.com>
> wrote:
> >
> > Can the variations be explained by GC pauses and other processes
> > using the
> > CPU?
> >
> > Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
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 <ga...@gmail.com> wrote:
>
> Can the variations be explained by GC pauses and other processes using the
> CPU?
>
> Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Nov 27, 2018 at 3:56 PM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2018-11-27 at 14:35 -0800, Ryan Schmitt wrote:
> > The sampling interval is not fixed, and JMH tries to auto-adjust it
> > (according to the documentation).
> >
>
> Such great deviation in number of samples makes no sense, regardless of
> what documentation says.
>
Can the variations be explained by GC pauses and other processes using the
CPU?
Gary
>
> Oleg
>
> > On Tue, Nov 27, 2018 at 2:10 PM Oleg Kalnichevski <ol...@apache.org>
> > wrote:
> > >
> > > Same benchmark time but different number of samples? This makes no
> > > sense.
> > >
> > > Oleg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2018-11-27 at 14:35 -0800, Ryan Schmitt wrote:
> The sampling interval is not fixed, and JMH tries to auto-adjust it
> (according to the documentation).
>
Such great deviation in number of samples makes no sense, regardless of
what documentation says.
Oleg
> On Tue, Nov 27, 2018 at 2:10 PM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > Same benchmark time but different number of samples? This makes no
> > sense.
> >
> > Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
The sampling interval is not fixed, and JMH tries to auto-adjust it
(according to the documentation).
On Tue, Nov 27, 2018 at 2:10 PM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> Same benchmark time but different number of samples? This makes no
> sense.
>
> Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2018-11-27 at 14:03 -0800, Ryan Schmitt wrote:
> 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
>
Same benchmark time but different number of samples? This makes no
sense.
Oleg
>
> On Tue, Nov 27, 2018 at 1:45 PM Oleg Kalnichevski <ol...@apache.org>
> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
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 <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2018-11-27 at 12:50 -0800, Ryan Schmitt wrote:
> Oh, that number appears to represent the number of invocations of the
> @Benchmark method. It's a numerator without a denominator; it has no
> meaning on its own. The important metrics are p0.50 (median execution
> time) and gc.alloc.rate (rate of heap allocation), since they
> directly
> address the questions of the time- and space-efficiency of Iterators
> that we are discussing in this thread.
>
> It's difficult to see just how identical these perf numbers are
> without a basis for comparison. I suggest changing `new ArrayList` to
> `new LinkedList` and re-running the benchmark in order to see the
> difference between iteration and repeated indexing in a linked list.
> Later this week, I may try to develop a variant of the benchmark that
> will defeat scalar replacement and force the JVM to allocate the
> Iterators on the heap in full, and therefore to GC them as well.
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
> On Tue, Nov 27, 2018 at 11:33 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > On Tue, 2018-11-27 at 11:12 -0800, Ryan Schmitt wrote:
> > > I'm not sure what point you're making with these numbers. They're
> > > effectively identical; the GC numbers in particular show no
> > > appreciable allocation or collection in either benchmark.
> > >
> >
> > I am also unsure what exactly you are trying to prove here but
> > 5041408
> > and 4310920 do not look effectively identical to me.
> >
> > Oleg
> >
> > > On Mon, Nov 26, 2018 at 4:05 AM Oleg Kalnichevski <
> > > olegk@apache.org>
> > > wrote:
> > > >
> > > > I clearly cannot agree with your conclusion based on the
> > > > numbers I
> > > > am
> > > > seeing locally.
> > > >
> > > > ---
> > > > Benchmark Mode Cnt Sco
> > > > re
> > > > Error Units
> > > > Testing6.index sample 5041408 51.9
> > > > 85
> > > > ± 0.244 ns/op
> > > > Testing6.index:index·p0.00 sample 31.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.50 sample 49.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.90 sample 52.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.95 sample 62.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.99 sample 70.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.999 sample 149.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:index·p0.9999 sample 3174.8
> > > > 73
> > > > ns/op
> > > > Testing6.index:index·p1.00 sample 46144.0
> > > > 00
> > > > ns/op
> > > > Testing6.index:·gc.alloc.rate sample 5 0.0
> > > > 07
> > > > ± 0.003 MB/sec
> > > > Testing6.index:·gc.alloc.rate.norm sample 5 ≈
> > > > 10⁻⁴ B/op
> > > > Testing6.index:·gc.count sample 5 ≈
> > > > 0 counts
> > > > Testing6.iterator sample 4310920 50.5
> > > > 87
> > > > ± 0.233 ns/op
> > > > Testing6.iterator:iterator·p0.00 sample 32.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.50 sample 48.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.90 sample 54.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.95 sample 56.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.99 sample 62.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.999 sample 115.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p0.9999 sample 1974.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:iterator·p1.00 sample 80896.0
> > > > 00
> > > > ns/op
> > > > Testing6.iterator:·gc.alloc.rate sample 5 0.0
> > > > 07
> > > > ± 0.002 MB/sec
> > > > Testing6.iterator:·gc.alloc.rate.norm sample 5 ≈
> > > > 10⁻⁴ B/op
> > > > Testing6.iterator:·gc.count sample 5 ≈
> > > > 0 counts
> > >
> > > ---------------------------------------------------------------
> > > ------
> > > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: dev-help@hc.apache.org
> > >
> >
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
Oh, that number appears to represent the number of invocations of the
@Benchmark method. It's a numerator without a denominator; it has no
meaning on its own. The important metrics are p0.50 (median execution
time) and gc.alloc.rate (rate of heap allocation), since they directly
address the questions of the time- and space-efficiency of Iterators
that we are discussing in this thread.
It's difficult to see just how identical these perf numbers are
without a basis for comparison. I suggest changing `new ArrayList` to
`new LinkedList` and re-running the benchmark in order to see the
difference between iteration and repeated indexing in a linked list.
Later this week, I may try to develop a variant of the benchmark that
will defeat scalar replacement and force the JVM to allocate the
Iterators on the heap in full, and therefore to GC them as well.
On Tue, Nov 27, 2018 at 11:33 AM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> On Tue, 2018-11-27 at 11:12 -0800, Ryan Schmitt wrote:
> > I'm not sure what point you're making with these numbers. They're
> > effectively identical; the GC numbers in particular show no
> > appreciable allocation or collection in either benchmark.
> >
>
> I am also unsure what exactly you are trying to prove here but 5041408
> and 4310920 do not look effectively identical to me.
>
> Oleg
>
> > On Mon, Nov 26, 2018 at 4:05 AM Oleg Kalnichevski <ol...@apache.org>
> > wrote:
> > >
> > > I clearly cannot agree with your conclusion based on the numbers I
> > > am
> > > seeing locally.
> > >
> > > ---
> > > Benchmark Mode Cnt Score
> > > Error Units
> > > Testing6.index sample 5041408 51.985
> > > ± 0.244 ns/op
> > > Testing6.index:index·p0.00 sample 31.000
> > > ns/op
> > > Testing6.index:index·p0.50 sample 49.000
> > > ns/op
> > > Testing6.index:index·p0.90 sample 52.000
> > > ns/op
> > > Testing6.index:index·p0.95 sample 62.000
> > > ns/op
> > > Testing6.index:index·p0.99 sample 70.000
> > > ns/op
> > > Testing6.index:index·p0.999 sample 149.000
> > > ns/op
> > > Testing6.index:index·p0.9999 sample 3174.873
> > > ns/op
> > > Testing6.index:index·p1.00 sample 46144.000
> > > ns/op
> > > Testing6.index:·gc.alloc.rate sample 5 0.007
> > > ± 0.003 MB/sec
> > > Testing6.index:·gc.alloc.rate.norm sample 5 ≈
> > > 10⁻⁴ B/op
> > > Testing6.index:·gc.count sample 5 ≈
> > > 0 counts
> > > Testing6.iterator sample 4310920 50.587
> > > ± 0.233 ns/op
> > > Testing6.iterator:iterator·p0.00 sample 32.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.50 sample 48.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.90 sample 54.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.95 sample 56.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.99 sample 62.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.999 sample 115.000
> > > ns/op
> > > Testing6.iterator:iterator·p0.9999 sample 1974.000
> > > ns/op
> > > Testing6.iterator:iterator·p1.00 sample 80896.000
> > > ns/op
> > > Testing6.iterator:·gc.alloc.rate sample 5 0.007
> > > ± 0.002 MB/sec
> > > Testing6.iterator:·gc.alloc.rate.norm sample 5 ≈
> > > 10⁻⁴ B/op
> > > Testing6.iterator:·gc.count sample 5 ≈
> > > 0 counts
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2018-11-27 at 11:12 -0800, Ryan Schmitt wrote:
> I'm not sure what point you're making with these numbers. They're
> effectively identical; the GC numbers in particular show no
> appreciable allocation or collection in either benchmark.
>
I am also unsure what exactly you are trying to prove here but 5041408
and 4310920 do not look effectively identical to me.
Oleg
> On Mon, Nov 26, 2018 at 4:05 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > I clearly cannot agree with your conclusion based on the numbers I
> > am
> > seeing locally.
> >
> > ---
> > Benchmark Mode Cnt Score
> > Error Units
> > Testing6.index sample 5041408 51.985
> > ± 0.244 ns/op
> > Testing6.index:index·p0.00 sample 31.000
> > ns/op
> > Testing6.index:index·p0.50 sample 49.000
> > ns/op
> > Testing6.index:index·p0.90 sample 52.000
> > ns/op
> > Testing6.index:index·p0.95 sample 62.000
> > ns/op
> > Testing6.index:index·p0.99 sample 70.000
> > ns/op
> > Testing6.index:index·p0.999 sample 149.000
> > ns/op
> > Testing6.index:index·p0.9999 sample 3174.873
> > ns/op
> > Testing6.index:index·p1.00 sample 46144.000
> > ns/op
> > Testing6.index:·gc.alloc.rate sample 5 0.007
> > ± 0.003 MB/sec
> > Testing6.index:·gc.alloc.rate.norm sample 5 ≈
> > 10⁻⁴ B/op
> > Testing6.index:·gc.count sample 5 ≈
> > 0 counts
> > Testing6.iterator sample 4310920 50.587
> > ± 0.233 ns/op
> > Testing6.iterator:iterator·p0.00 sample 32.000
> > ns/op
> > Testing6.iterator:iterator·p0.50 sample 48.000
> > ns/op
> > Testing6.iterator:iterator·p0.90 sample 54.000
> > ns/op
> > Testing6.iterator:iterator·p0.95 sample 56.000
> > ns/op
> > Testing6.iterator:iterator·p0.99 sample 62.000
> > ns/op
> > Testing6.iterator:iterator·p0.999 sample 115.000
> > ns/op
> > Testing6.iterator:iterator·p0.9999 sample 1974.000
> > ns/op
> > Testing6.iterator:iterator·p1.00 sample 80896.000
> > ns/op
> > Testing6.iterator:·gc.alloc.rate sample 5 0.007
> > ± 0.002 MB/sec
> > Testing6.iterator:·gc.alloc.rate.norm sample 5 ≈
> > 10⁻⁴ B/op
> > Testing6.iterator:·gc.count sample 5 ≈
> > 0 counts
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
I'm not sure what point you're making with these numbers. They're
effectively identical; the GC numbers in particular show no
appreciable allocation or collection in either benchmark.
On Mon, Nov 26, 2018 at 4:05 AM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> I clearly cannot agree with your conclusion based on the numbers I am
> seeing locally.
>
> ---
> Benchmark Mode Cnt Score Error Units
> Testing6.index sample 5041408 51.985 ± 0.244 ns/op
> Testing6.index:index·p0.00 sample 31.000 ns/op
> Testing6.index:index·p0.50 sample 49.000 ns/op
> Testing6.index:index·p0.90 sample 52.000 ns/op
> Testing6.index:index·p0.95 sample 62.000 ns/op
> Testing6.index:index·p0.99 sample 70.000 ns/op
> Testing6.index:index·p0.999 sample 149.000 ns/op
> Testing6.index:index·p0.9999 sample 3174.873 ns/op
> Testing6.index:index·p1.00 sample 46144.000 ns/op
> Testing6.index:·gc.alloc.rate sample 5 0.007 ± 0.003 MB/sec
> Testing6.index:·gc.alloc.rate.norm sample 5 ≈ 10⁻⁴ B/op
> Testing6.index:·gc.count sample 5 ≈ 0 counts
> Testing6.iterator sample 4310920 50.587 ± 0.233 ns/op
> Testing6.iterator:iterator·p0.00 sample 32.000 ns/op
> Testing6.iterator:iterator·p0.50 sample 48.000 ns/op
> Testing6.iterator:iterator·p0.90 sample 54.000 ns/op
> Testing6.iterator:iterator·p0.95 sample 56.000 ns/op
> Testing6.iterator:iterator·p0.99 sample 62.000 ns/op
> Testing6.iterator:iterator·p0.999 sample 115.000 ns/op
> Testing6.iterator:iterator·p0.9999 sample 1974.000 ns/op
> Testing6.iterator:iterator·p1.00 sample 80896.000 ns/op
> Testing6.iterator:·gc.alloc.rate sample 5 0.007 ± 0.002 MB/sec
> Testing6.iterator:·gc.alloc.rate.norm sample 5 ≈ 10⁻⁴ B/op
> Testing6.iterator:·gc.count sample 5 ≈ 0 counts
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2018-11-25 at 11:26 -0800, Ryan Schmitt wrote:
> I threw together a quick JMH benchmark which shows that the iterator
> is completely optimized out (results at bottom):
>
> https://pastebin.com/eS7GbmNx
>
> I take this as a demonstration of a more general principle, which is
> that basic patterns in Java programming (e.g. virtual method calls,
> object creation) tend to be extremely heavily optimized at runtime,
> and avoiding them as a matter of principle is usually
> counterproductive.
>
I clearly cannot agree with your conclusion based on the numbers I am
seeing locally.
---
Benchmark Mode Cnt Score Error Units
Testing6.index sample 5041408 51.985 ± 0.244 ns/op
Testing6.index:index·p0.00 sample 31.000 ns/op
Testing6.index:index·p0.50 sample 49.000 ns/op
Testing6.index:index·p0.90 sample 52.000 ns/op
Testing6.index:index·p0.95 sample 62.000 ns/op
Testing6.index:index·p0.99 sample 70.000 ns/op
Testing6.index:index·p0.999 sample 149.000 ns/op
Testing6.index:index·p0.9999 sample 3174.873 ns/op
Testing6.index:index·p1.00 sample 46144.000 ns/op
Testing6.index:·gc.alloc.rate sample 5 0.007 ± 0.003 MB/sec
Testing6.index:·gc.alloc.rate.norm sample 5 ≈ 10⁻⁴ B/op
Testing6.index:·gc.count sample 5 ≈ 0 counts
Testing6.iterator sample 4310920 50.587 ± 0.233 ns/op
Testing6.iterator:iterator·p0.00 sample 32.000 ns/op
Testing6.iterator:iterator·p0.50 sample 48.000 ns/op
Testing6.iterator:iterator·p0.90 sample 54.000 ns/op
Testing6.iterator:iterator·p0.95 sample 56.000 ns/op
Testing6.iterator:iterator·p0.99 sample 62.000 ns/op
Testing6.iterator:iterator·p0.999 sample 115.000 ns/op
Testing6.iterator:iterator·p0.9999 sample 1974.000 ns/op
Testing6.iterator:iterator·p1.00 sample 80896.000 ns/op
Testing6.iterator:·gc.alloc.rate sample 5 0.007 ± 0.002 MB/sec
Testing6.iterator:·gc.alloc.rate.norm sample 5 ≈ 10⁻⁴ B/op
Testing6.iterator:·gc.count sample 5 ≈ 0 counts
> On Sun, Nov 25, 2018 at 9:30 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > I do not need to provide anything. If there is no intermediate
> > garbage,
> > there is no GC overhead. It is that simple.
> >
> > Oleg
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
I threw together a quick JMH benchmark which shows that the iterator
is completely optimized out (results at bottom):
https://pastebin.com/eS7GbmNx
I take this as a demonstration of a more general principle, which is
that basic patterns in Java programming (e.g. virtual method calls,
object creation) tend to be extremely heavily optimized at runtime,
and avoiding them as a matter of principle is usually
counterproductive.
On Sun, Nov 25, 2018 at 9:30 AM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> I do not need to provide anything. If there is no intermediate garbage,
> there is no GC overhead. It is that simple.
>
> Oleg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2018-11-25 at 10:17 -0700, Gary Gregory wrote:
> On Sun, Nov 25, 2018 at 3:19 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
>
> > On Sat, 2018-11-24 at 21:43 -0800, Ryan Schmitt wrote:
> > > Where's the grief, exactly? The fact that these objects are
> > > showing
> > > up
> > > in heap dumps does not imply performance impact, and no
> > > performance
> > > impact was claimed, nor were any measurements provided. To state
> > > that
> > > iterators "have to be garbage collected" is misleading; the Java
> > > garbage collector traces live objects, never looking at garbage,
> > > which
> > > means that ephemeral garbage is virtually free.
> >
> > Please quantify being 'virtually free' and provide measurements to
> > support the claim.
> >
>
> Oh boy, it feels like all sides are claiming some performance
> characteristics and in each case the other side is asking for
> evidence...
> :-(
>
I do not need to provide anything. If there is no intermediate garbage,
there is no GC overhead. It is that simple.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Nov 25, 2018 at 3:19 AM Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sat, 2018-11-24 at 21:43 -0800, Ryan Schmitt wrote:
> > Where's the grief, exactly? The fact that these objects are showing
> > up
> > in heap dumps does not imply performance impact, and no performance
> > impact was claimed, nor were any measurements provided. To state that
> > iterators "have to be garbage collected" is misleading; the Java
> > garbage collector traces live objects, never looking at garbage,
> > which
> > means that ephemeral garbage is virtually free.
>
> Please quantify being 'virtually free' and provide measurements to
> support the claim.
>
Oh boy, it feels like all sides are claiming some performance
characteristics and in each case the other side is asking for evidence...
:-(
Gary
>
> Oleg
>
>
> > You also have to
> > consider JVM optimizations like scalar replacement, which is
> > basically
> > an approximation of stack allocation. Gary also makes a good point
> > about how replacing iteration with index access on a List can
> > backfire
> > depending on the underlying implementation of List.
> >
> > On Fri, Nov 23, 2018 at 12:20 AM Oleg Kalnichevski <ol...@apache.org>
> > wrote:
> > >
> > > I am _strongly_ against it. Last time you did that it had caused us
> > > a
> > > lot of grief.
> > >
> > > https://issues.apache.org/jira/browse/HTTPCORE-361
> > >
> > > Oleg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> > For additional commands, e-mail: dev-help@hc.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2018-11-24 at 21:43 -0800, Ryan Schmitt wrote:
> Where's the grief, exactly? The fact that these objects are showing
> up
> in heap dumps does not imply performance impact, and no performance
> impact was claimed, nor were any measurements provided. To state that
> iterators "have to be garbage collected" is misleading; the Java
> garbage collector traces live objects, never looking at garbage,
> which
> means that ephemeral garbage is virtually free.
Please quantify being 'virtually free' and provide measurements to
support the claim.
Oleg
> You also have to
> consider JVM optimizations like scalar replacement, which is
> basically
> an approximation of stack allocation. Gary also makes a good point
> about how replacing iteration with index access on a List can
> backfire
> depending on the underlying implementation of List.
>
> On Fri, Nov 23, 2018 at 12:20 AM Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > I am _strongly_ against it. Last time you did that it had caused us
> > a
> > lot of grief.
> >
> > https://issues.apache.org/jira/browse/HTTPCORE-361
> >
> > Oleg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Ryan Schmitt <rs...@apache.org>.
Where's the grief, exactly? The fact that these objects are showing up
in heap dumps does not imply performance impact, and no performance
impact was claimed, nor were any measurements provided. To state that
iterators "have to be garbage collected" is misleading; the Java
garbage collector traces live objects, never looking at garbage, which
means that ephemeral garbage is virtually free. You also have to
consider JVM optimizations like scalar replacement, which is basically
an approximation of stack allocation. Gary also makes a good point
about how replacing iteration with index access on a List can backfire
depending on the underlying implementation of List.
On Fri, Nov 23, 2018 at 12:20 AM Oleg Kalnichevski <ol...@apache.org> wrote:
>
> I am _strongly_ against it. Last time you did that it had caused us a
> lot of grief.
>
> https://issues.apache.org/jira/browse/HTTPCORE-361
>
> Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Enhanced for-loops
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2018-11-22 at 20:12 -0700, Gary Gregory wrote:
> Hi All:
>
> In the HC code base, we could avoid some boilerplate clutter by using
> Java's enhanced for-loop construct. I believe this would make the
> code
> easier to read. Are there any objections to making this change?
>
> Gary
I am _strongly_ against it. Last time you did that it had caused us a
lot of grief.
https://issues.apache.org/jira/browse/HTTPCORE-361
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org