Slow compilation with a lot of type inference

[Maurizio Cimadamore]

Hi,
we already have entries for those:

https://bugs.openjdk.java.net/browse/JDK-8152289

and

https://bugs.openjdk.java.net/browse/JDK-8221301

In javac we are doing a lot of heroics to try and keep the space of 
inference variable as small as possible, by aggressively de-duping 
inference variables where possible. This strategy works well in cases like:

a(b(c(d(...)))))

But in cases like the ones you report (or those in the JBS issues 
above), which have a shape like:

a(b(), c(), d(), e() ... )

We do not yet perform any de-duping, so the inference engine has to run 
with a very big set of (possibly very similarly looking) inference 
variables. Performing incorporation will end up setting similarly 
looking bounds on the inference variables of the outer a() call, which 
all have to be validated, and so on and so forth.

I think de-duping cases like these is still possible, but it's a change 
that probably cuts much deeper into the inference engine - and we have 
been holding off on that when we fixed the main inference performance 
issue in Java 8/9, although I understand that with the Collection 
factories, idioms like these just got a lot more common.

Cheers
Maurizio



On 22/07/2021 03:03, Vicente Romero wrote:
> Hi Nir,
>
> We have done a lot of work to speed up inference, unfortunately it is 
> always possible to generate code that will make the inference engine 
> look bad, please file a bug in our JIRA system with all of your 
> findings and we will get to it when possible,
>
> Thanks,
> Vicente
>
> On 7/19/21 1:13 PM, Nir Lisker wrote:
>> Hi,
>>
>> I have recently submitted an Eclipse bug [1] regarding very slow 
>> compilation when a lot of type inference is required. The report 
>> includes an example case, which looks like:
>>
>> public static final Map<String, String> DESC = Map.ofEntries(
>>     Map.entry("A", "B"),
>>     Map.entry("A", "B"),
>>     Map.entry("A", "B"),
>>     // many more of these
>> );
>>
>> The Eclipse developer shows that the slowness happens in javac as 
>> well. I understand that every entry needs to be looked at to find the 
>> type for Map.ofEntries, and the problem can be resolved by adding 
>> Map.<String, String>ofEntries, but I thought it's worth asking here too.
>>
>> Is this considered normal behavior?
>>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732 
>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=574732>
>>
>> - Nir
>