[Checkers] NonNull checker Performance
mpapi at csail.mit.edu
Mon Apr 21 19:25:33 EDT 2008
Thanks! That information was very helpful.
I just got rid of the use of getPath() in nearestEnclosing via
visitorState. (This one's especially important since that call is part
of the implementation for @Default and moving that into the framework
is high on my todo list.)
There's a call to each of getPath() and declarationFromElement() to
work around the (Sun) bug in javac in which elements for exception
parameters have the kind PARAMETER instead of EXCEPTION_PARAMETER. I
think I've found a way to get rid of both calls.
On Mon, Apr 21, 2008 at 7:02 PM, Mahmood Ali <mahmood at mit.edu> wrote:
> 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
> > 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
> - 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
More information about the checkers