Performance of Scope.getSymbolsByName()

Jan Lahoda jan.lahoda at
Fri May 17 15:21:30 UTC 2019

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.


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!

More information about the compiler-dev mailing list