Performance of Scope.getSymbolsByName()

Ron Shapiro ronshapiro at
Mon May 20 20:34:17 UTC 2019

This patch, which materializes the duplicate outer and inner Iterables
first into a list. It removes the entire section of the CompoundIterator
iteration from the profile.


I'm not sure it's the absolutely correct solution as it possibly masks an
underlying issue.

I'm still seeing some time spent in MethodSymbol.overrides,
Types.isSubSignature, and Types.memberType, all of which happen in the
inner loop. If we can remove those and collapse the nested loops into one,
then this solution isn't necessary and it would also solve that performance

On Fri, May 17, 2019 at 5:55 PM Ron Shapiro <ronshapiro at> wrote:

> 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:
> On Fri, May 17, 2019 at 11:21 AM Jan Lahoda <jan.lahoda at> 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: <>

More information about the compiler-dev mailing list