[Checkers] NonNull checker Performance
mahmood at MIT.EDU
Mon Apr 21 19:02:05 EDT 2008
On Apr 21, 2008, at 2:49 PM, Matt Papi wrote:
>> That is long, but it doesn't take very long to compile. Is there
>> remaining inefficiency in the checker?
> There could very well be. However, I don't expect the NonNull checker
> to be as fast as, say, the Interned checker; NonNull calls into the
> factory for every member select [...]. It does seem like it's slower
> than it
> should be, but not so slow as to be alarming at this point.
I ran the profiler in a VM (so it's significantly slower there than in
my machine) with a random three files in daikon and
FunctionBinary.java. The top four bottle-neck methods are:
- Trees.getPath() -- 150 seconds (49% of total time) average
time: 4.9s invocations: 30,237
Basically as a result of NonNullAnnotatedTypeFactory.nearestEnclosing()
- TreeInfo.declarationFor() -- 27.7 seconds (9% total time) average
time: 3.2s invocations: 8,672
All calls are from AnnotatedTypeFactory.declarationFromElement()
Note: Internally, declarationFor() does a search also for all the ASTs
to get the declaration.
- TreePath.getPath() -- 16.6 seconds (5% total time) average time:
3.7s invocations: 4,422
All calls are from TypeFromTree$TypeFromMember.visitVariable()
- Element.getAnnotation() -- 6 seconds (2% total time) average time:
10ns invocations: 675,292.
While NonNull checks every single member select, it is not obvious to
me that it's the reason. AnnotatedTypeFactory.getAnnotatedType()
amounts to just less than 3 seconds (0%) of the total run time.
More information about the checkers