Yesterday I had posted the following latest profiler numbers:
>>> "Eric M. Ludlam" <eric@...> seems to think that:
[ ... ]
>2.7 sec (include path)
>.09 sec (typecache)
>.18 sec (scope)
>18.9 sec (analysis)
>.0003 sec (completion)
>19.4 sec or .3 minutes
>Huzzah! The better news is that most of that 19.4 seconds is the ELP
>book keeping so actual run-time is around 1 second. I suspect I can
>get some more since it still calls `semantic-equivalent-tag-p' 527075
>times, which seems a little excessive.
I have since found the 527075 calls and eliminated most of them. Here
are some new numbers:
3.2 sec (include path)
.08 sec (typecache)
.18 sec (scope)
.14 sec (analysis)
.0003 sec (completion)
3.6 seconds, or .06 min
This time it was C specific. The way to determine the protection of
some tag in a class was to scan the member list and associate the
public: type label to the tag. That was then used poorly. C now has
a custom "find all the public tags" search routine.
When I started this profiler thing I was expecting to have to work
hard to find ways to cache data or whatever, or eliminate various
iterations. It has turned out there was just a lot API stack where
seemingly innocuous APIs were being used too much or had unexpected
side effects... like loading a file into a buffer. It's really quite
amazing to me how fast the analyzer is now on my massive code-base at
work. It has shifted from "Ugh, stop it" to unnoticeable and useful
after the include path is calculated and cached.
Someone on emacs-devel recently posted a patch to ELP for adding
call-tree support. That ought to be handy.
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net