Slow compilation with a lot of type inference

[Nir Lisker]

I understand. Thanks.

- Nir

On Thu, Jul 22, 2021 at 1:39 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210722/114c30d1/attachment.htm>