RFR: 8026369: javac potentially ambiguous overload warning needs an improved scheme [v3]

[Archie L. Cobbs]

On Fri, 24 Feb 2023 19:49:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> I think the code should be split a bit using helper methods
>> 
>> OK - will do.
>> 
>>> I'm a bit worried that overuse of streams in this code could imply some performance hit
>> 
>> I asked basically the same question ([in a separate thread](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022259.html)) two days ago and nobody replied with a definitive answer (not surprising).
>> 
>> However, note also that in that same thread Christoph reported no timing difference between `Stream` vs. `for()` loop ([here](https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022261.html)), although there were more allocations. FWIW.
>> 
>> Sorry to go off on a tangent here, but I'm sure this issue will come up again and it would be nice to have some kind of (informal) policy to go on...
>> 
>> I generally try to follow the "measure first, optimize second" rule to avoid preemptive "optimizations" that come at the expense of code clarity for unproven meaningful benefit.
>> 
>> So I can de-`Stream` the code but are we sure it's worth it? Are we going to have a no `Stream` policy in the compiler code? Why did we develop `Stream`'s if they can't be used in a mainstream tool like `javac`? Where does the madness end? :)
>> 
>> There is also the larger philosophical question as well, which is that if a `Stream` is appreciably slower than the semantically-equivalent `for()` loop, then isn't that a Hotspot problem, not a developer problem?
>
> I'm not saying that we should de-stream the code, actually we can do that later on, in a separate issue, iff there is a performance related complain, but it is true that in the past, I have seen some performance issues and the final culprit have been streams. But you are right it could be that it is not worthy to affect the readability of the code.

OK thanks, I'll leave it for now - but it would be nice to (someday) do some comprehensive testing so we have a better intuitive understanding of the performance impact of using a `Stream` in any particular situation.

I wonder if there is some IDE tool that could automatically `Stream`ify and/or de-`Stream`ify loops. If so, we could apply it to the entire compiler and compare...

-------------

PR: https://git.openjdk.org/jdk/pull/12645