>>> bread <breaddawson@...> seems to think that:
>On Mon, Dec 8, 2008 at 12:27 AM, Eric M. Ludlam <eric@...:
>> Due to polymorphism in some languages, it searches all the header
>> files. A second pass over those search results throw out bad hits.
>I recalled that the cache of the header files will not be cleared if they
>are not touched. But i found that if i do this, for example,
>// some codes here declare the type of variable foo
>I had to wait a long time before getting the completions for the first time
>which could be predicted because there're really many header files. But if i
>deleted the line above, and re-type "foo.", and get completions again. It
>will still cost a long time. I'm confused because this file have only
>several lines, so i don't think re-analyze this file is time consuming. But
>since other files are not touched at all, they do not need to be
I think that the second time should be fine. There are several caches
saved and flushed during editing. The primary is the raw tags list in
all the headers. Those should not be cleared. Another is the type
cache. The typecache has two levels. The include cache, and the
local file cache. If you edit the local file, it should not clear the
include cache, which is the slow one to regenerate.
Another cache is the scope cache, which is where local context,
inheritance, using statements and the like are cached. That gets
flushed as you move from function to function.
Lastly, the analyzer results are cached, but that gets cleared as you
move from statement to statement.
If you have a simple motion that cause slowness, go to recreate it,
but instead of using normal completion, use the profiler:
M-x semantic-elp-analyze RET
It will prompt you to save the profiler results in a file which you
could email me. Alternately, you can look through the results
yourself, and perhaps you will learn something yourself.
>> For most of the analyzer, however, it collects all the datatypes and
>> names spaces into one big cache. Searching in that cache is pretty
>> fast, but building it can be a bit slow the first time. There is a
>> complex cache-clearing system so only flush the typecache when
>> targeted things change.
>> It might be possible to rig up typecache resets to a key command
>> instead of being automatic. This would speed things up, but you would
>> not get your most recent edits accounted for.
>I think this is a good idea since if i can control when to analyzing, i can
>also use it when i need recent changes to take effects. Would you mind to
>provide more details about this or share some configurations of yourself? It
>will be greatly helpful to me because the main problems i encountered now is
>that it takes too long before the completions show up. I think most of the
>time 2-3 seconds is a more reasonable period and i'm willing to use some
>spaces, for example, the cache can be much larger or something else to
>optimize the efficiency ( I don't know exactly if this can be done i just
>use this as an example). CEDET is a great tool, but it will be better if
[ ... ]
I'll look into adding such an option, but it may be wise to profile it
first to find out who the real culprit is.
Eric Ludlam: eric@...
Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net