Re: [CEDET-devel] On large project, CEDET analysis takes ~10s

[Eric M. L. <er...@si...>]

On 10/16/2010 08:06 PM, David Schroeder wrote:
> To begin, I may be configuring things wrong.  I only recently got CEDET set up based on instructions from the website (specifically, on http://cedet.sourceforge.net/projects.shtml for the "custom build script")
>
> I have a large project which has several large sub-libraries.  One of these libraries is G3D (g3d.sf.net) which has around 70k lines in headers.  Miscellaneous other libraries probably add 30k or so more lines, and I also use stdc++.  However, I've seen screenshots from people using CEDET and Semantic with Qt, which seems to be a larger and more complicated project that what I have.
>
> When I use semantic-ia-complete-symbol-menu, I need to wait for around 10s or so for the menu to appear.  Using semantic-speedbar-analysis, my Emacs freezes up nearly solidly.  M-x semantic-load-enable-gaudy-code-helpers is just a very very bad idea.
>
> I am using Emacs 23.2 on OS X.  I am using cedet-1.0 from cedet.sf.net, and followed the compilation instructions in cedet-build.el.  I'm not using etags, ctags, or cscope, since instructions I saw online hinted that these couldn't handle template parameters well.
>
> Any help would be greatly appreciated, and this hurdle is all that's keeping me from having Emacs satisfy my every code-editing need.

Hi,

David Engster provided a pretty good answer, but I wanted to follow up a 
little.

When a set of Semantic tags tables grows larger than what Emacs can 
support without causing a machine to swap, everything goes slower.  By 
everything, I mean the Emacs garbage collector which is run before every 
parse, and at other random times.

This is one of those unforseen problems that showed up for me also, but 
I don't have a good solution.  My intention is to design and build an 
external process for handing large tag tables, and have Emacs offload 
that storage, possibly allowing Emacs to only store those parts actually 
needed.  The external program would need to do something clever to keep 
things on disk with indexes.  GNU Global does this pretty well and can 
search huge projects quite quikly.  Unfortunately, that will be a while 
before something like that is generally usable.

Eric