Hi,
My thought was to introduce some sort of association list, though it
is complex enough, a class might be needed. Source code will need to
be changed to do it though.
For example:
(defcustom semanticdb-project-root-includes nil
"*List of roots associated with project include paths for those roots.
Each entry is of the form:
(ROOTDIR . MODE DIR DIR DIR...)"
:group 'semanticdb
:type '(repeat (cons :tag "Root Entry"
(string :tag "Root")
(cons :tag ""
(symbol :tag "Mode")
(repeat :tag "Include List"
(string :tag "Include Dir"))))))
Then, in semanticdb-current-database-list, there is some code like
this:
(while rootlist
(setq root (car rootlist))
(let ((regexp (concat "^" (regexp-quote (expand-file-name root))))
(adb semanticdb-database-list) ; all databases
)
(while adb
this looks at all known databases that are rooted to ROOT above.
In this case, look something up from the variable above. If you find
something, explicitly load just those databases and return them. If
not, then do the old thing.
I'm happy to do this if you are not comfortable with it, it'll just be
a couple days (or perhaps a week) before I get to it, as I'm leaving
on vacation in a couple days.
The good news, is that after one run looking these things up in your
source, it will remember on a per-tag instance where to find each
file, so it won't need to do that long lookup a second time.
Eric
>>> "Ashish Hanwadikar" <ahanwadi@...> seems to think that:
>------=_Part_101922_26908202.1182557923617
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline
>
>Eric,
> Yes, it is a very large number: 150. How do I optimize the lookup
>without modifying the source code?
>Thanks,
>Ashish
>
>On 6/22/07, Eric M. Ludlam <eric@...> 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
>> path.
>>
>> Eric
>>
>>
>>
>> >>> "Ashish Hanwadikar" <ahanwadi@...> seems to think that:
>> >------=_Part_100882_13746067.1182545433257
>> >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.
>> >
>> >Thx,
>> >Ashish
>> >
>> >On 6/22/07, Eric M. Ludlam <eric@...> 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" <ahanwadi@...> 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: zappo@...,
>> >> eric@...
>> >> Home: http://www.ludlam.net Siege: http://www.siege-engine.com
>> >> Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
>> >>
>> >
>> >
>> >
>>
>> --
>> 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
>>
>
>
>
--
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
|