The analyzer is indeed the slowest piece of the puzzle. If you've
used the analyzer, you will see that it provides a lot of information,
such as all the data types of the prefix. Without that, the part that
actually completes words could not work reliably.
It seems likely to me that there are ways to make it faster, but I
hadn't profiled it much.
Another option for completion is senator-complete-symbol. It uses a
simpler mechanism, but does not filter based on data types.
The analyzer has cache already. It uses `semantic-get-cache-data'
which is a fancy way to bind lisp objects to a region on the buffer
that is relevant. To keep it up to date, it gets flushed when the
cursor leaves the specified region.
It is not clear to me if a completion cache from the analyzer is
useful. Each completion list is specific to a particular function
tag. It probably is possible to bind a general context to a file, and
a separate private context to each function or method, and merge
before doing completions. Such a cache would remember the lists of
files to search.
Each time a search is made (from the semanticdb-find routines) it
needs to recalculate the list of files it can search. If speed is an
issue, you can modify the `semanticdb-find-default-throttle' on a
per-buffer basis. Tuning this basically allows you trade off time
consuming parts of the search if you don't need that part of the
accuracy. A longer term solution might be to remember on a per-buffer
what the list of include files to search might be.
>>> <klaus.berndl@...> seems to think that:
>thanks for your efforts - i agree with your analysis - i have forwared =
>posting to the cedet-mailing list, because i hope, Eric oder david can =
>us some pointers how to solve the problems...
>Eric, David, thoughts?
>Von: ecb-list-admin@... im Auftrag von Dan Debertin
>Gesendet: Fr 19.08.2005 16:13
>Betreff: [ECB-list] Re: Analyser performance
>Okay, I have added some basic caching to ecb-analyse-buffer-sync. It
>caches lists of possible completions, keyed on partial symbol
>names. This did not immediately improve performance, though it did get
>slightly better as the cache began to be populated. Here are the
>1. Cache coherence. We have no way to tell if the list of possible
> completions has changed since we cached an entry.
>2. Have to write the cache out to disk between ECB sessions and read
> it in later. As the cache is simply a hash table, it shouldn't be
> too hard.
>But the real kicker is no. 3: It isn't
>semantic-analyze-possible-completions that's causing performance
>problems, it's semantic-analyze-current-context! Profiling shows that
>of the average 1.02 seconds it takes analyse-buffer-sync to run, 0.94
>seconds are spent in semantic-analyze-current-context.=20
>So I'm up against a wall. I don't know a lot about semantic internals,
>but if there's a way to speed analyze-current-context up or use a more
>lightweight function, I would like to know it.
[ ... ]
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org