[Checkers] NonNull checker Performance

[Mahmood Ali]

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  
>> some
>> 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.

- Mahmood