Performance of Scope.getSymbolsByName()

[Ron Shapiro]

I still have more to investigate to fully wrap my head around it, but I
finally found a sample program that exhibits this. Filed a bug here:
https://bugs.openjdk.java.net/browse/JDK-8224161

On Fri, May 17, 2019 at 11:21 AM Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi Ron,
>
> I am afraid it is hard to guess what is the problem without some
> testcase. So, at least to me, having a sample would be helpful.
>
> Thanks,
>      Jan
>
> On 17. 05. 19 0:41, Ron Shapiro wrote:
> > Hi,
> >
> > I'm observing a particularly bizarre compilation. It's a single file
> > with annotation processing, and the type that is being compiled and
> > processed has ~1000 declared and inherited methods combined. The total
> > compilation is 3 minutes, but 65% of the entire compilation is spent in
> > 3 methods:
> > Check.checkOverrideClashes(), Resolve.findInheritedMemberType(),
> > and Resolve.findField().
> >
> > Looking at profiles, it looks like getSymbolsByName() is the major
> > culprit here. I initially thought the reason was that there were far too
> > many overloads (this type had >600 overloads...) and that that was
> > causing a bad regression for the pseudo-hashmap that ScopeImpl uses.
> > However, renaming the methods did not alleviate the build pain and these
> > methods continue to be taking long amounts of time.
> >
> > I was wondering what could be done to improve the performance of this
> > code. It seemed to me that something like a Map<Name, List<Symbol>>
> > could be a reasonable+modern replacement for this table, which would
> > naturally have a fast getSymbolsForName() implementation. I'm having
> > some trouble implementing it correctly, and I believe it's partially
> > related to not fully understanding some of the semantics of the class.
> >
> > Does what I wrote make sense to anyone, and maybe spark a lightbulb?
> >
> > I'm trying to put together a repro in case that helps, but I'm not 100%
> > sure I even understand what the regression case is.
> >
> > Thanks for you help!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190517/5bf85417/attachment-0001.html>