Yes, it is a very large number: 150. How do I optimize the lookup without modifying the source code?

On 6/22/07, Eric M. Ludlam <> wrote:
I suspect, that to help with the speed of your project, you are
interested in the function `semanticdb-current-database-list'.  If you
do this in your file:

M-: (length (semanticdb-current-database-list)) RET

and it returns a big number, like 20, or 100, then this is the core
problem.  Semantic doesn't know what your actual include path is, so
it assumes the entirety of your project.

If your project has one place, like root/include, for all includes,
then you could probably optimize semanticdb-current-database-list
to only check the paths in some sort of project-specific search


>>> "Ashish Hanwadikar" <> seems to think that:
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>Actually, I am using semanticdb project roots. After I removed the recursive
>option, it is working fine (although, it cannot do intellisense completion
>if I used a symbol or struct from a file that is only indirectly included).
>I can live with that currently. I am prepared to spend some time to fix this
>issue, but I will need a few pointers as to where to start. I was able to
>turn on edebug on quit/error and then step through the code in
>semanticdb-find.el. But I don't know when exactly the semanticdb-database is
>created and how does it go recursively through the paths.
>On 6/22/07, Eric M. Ludlam <> wrote:
>> Hi,
>>   I submitted a change to semantic-tag-file.el which should help in
>> this case where the #include is a <system> include, and where your
>> project is help inside EDE.
>>   If that is not the case, and it is just using the semanticdb project
>> roots, then I'll need to look into it some more.
>>   Thanks for identifying this.  It ought to lead to some good
>> optimizations.
>> Eric
>> >>> "Ashish Hanwadikar" <> seems to think that:
>> >I am trying to setup semantic intellisense for a large project (possibly
>> >more than 1000 files). It is extremely slow and thus, unusable in the
>> >current state. The relevant .emacs is at the end of this email. I found
>> out
>> >using 'strace' that it is trying to locate the include file (say, include
>> ><b/a.h>) in my project. The algorithm seems to be the following:
>> >1) try, current directory/b/a.h -- Not found
>> >2) then, current directory/a.h -- Not found
>> >3) the, for each subdirectory in the system include path, try, system
>> >include dir/subdir/b/a.h -- Not found
>> >
>> >The last step, takes a lot of time as it has to through hundreds of sub
>> >directories. Just like the step 1), why doesn't it directly try, system
>> >include dir/b/a.h? It will find that file immediately.
>> >
>> >I don't know enough lisp to fix this. But if somebody can point to me
>> where
>> >I should be looking for, I am willing to give it a try.
>> >
>> >thanks in advance,
>> >Ashish Hanwadikar
>>   [ ... ]
>> --
>>           Eric Ludlam:        ,
>>    Home:            Siege:
>> Emacs:               GNU:

          Eric Ludlam:       ,
   Home:            Siege:
Emacs:               GNU:

Ashish Hanwadikar