CEDET

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.

Thanks!

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: David Engster <deng@ra...> - 2010-10-17 08:05 David Schroeder writes: > 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. Does it really always take ~10s? It may very well take that long the first time you query the analyzer on a certain class, but subsequent completions on the same class should be much faster, also between sessions. Emacs caches all the semantic information from headers it has parsed to disc (by default in ~/.semanticdb). The first parsing of those headers can be time consuming for a large codebase; for instance, parsing (most of) the STL takes maybe 1-2 minutes on my slow notebook. CEDET will start parsing either when Emacs has been idle for a minute, or when you enforce it through completion or other Semantic features (like speedbar-analysis). So the only advice I can give you is to give Emacs some time until it has parsed most of your headers. If you encounter a completion which *always* takes several seconds until it appears, please post an example here. -David

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: David Schroeder <medgno@me...> - 2010-10-17 16:01 Attachments: Message as HTML      I gave my emacs a good amount of time to finish parsing everything, letting it run overnight. Still, the first time I ask for a completion, I need to wait at least ten seconds, and sometimes longer. If I immediately ask for the same completion, it's instant. However, if I ask for a different completion and then the first one, I still have the same length wait. My semanticdb folder is 11M, and one of the files is 2.7M large. Is this larger than semantic is able to handle well? On Oct 17, 2010, at 3:05 AM, David Engster <deng@...> wrote: > David Schroeder writes: >> 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. > > Does it really always take ~10s? It may very well take that long the > first time you query the analyzer on a certain class, but subsequent > completions on the same class should be much faster, also between > sessions. Emacs caches all the semantic information from headers it has > parsed to disc (by default in ~/.semanticdb). The first parsing of those > headers can be time consuming for a large codebase; for instance, > parsing (most of) the STL takes maybe 1-2 minutes on my slow > notebook. CEDET will start parsing either when Emacs has been idle for a > minute, or when you enforce it through completion or other Semantic > features (like speedbar-analysis). > > So the only advice I can give you is to give Emacs some time until it > has parsed most of your headers. If you encounter a completion which > *always* takes several seconds until it appears, please post an example > here. > > -David > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: Christopher Barry <christopher.barry@ra...> - 2010-10-17 16:17 Just a thought, but have you considered trying running the db from a tmpfs? This would eliminate any disk-based latencies in your analysis. -C On Sun, 2010-10-17 at 11:01 -0500, David Schroeder wrote: > I gave my emacs a good amount of time to finish parsing everything, > letting it run overnight. Still, the first time I ask for a > completion, I need to wait at least ten seconds, and sometimes > longer. If I immediately ask for the same completion, it's instant. > However, if I ask for a different completion and then the first one, > I still have the same length wait. > > My semanticdb folder is 11M, and one of the files is 2.7M large. Is > this larger than semantic is able to handle well? > > > > > On Oct 17, 2010, at 3:05 AM, David Engster <deng@...> > wrote: > > > > > David Schroeder writes: > > > 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. > > > > Does it really always take ~10s? It may very well take that long the > > first time you query the analyzer on a certain class, but subsequent > > completions on the same class should be much faster, also between > > sessions. Emacs caches all the semantic information from headers it > > has > > parsed to disc (by default in ~/.semanticdb). The first parsing of > > those > > headers can be time consuming for a large codebase; for instance, > > parsing (most of) the STL takes maybe 1-2 minutes on my slow > > notebook. CEDET will start parsing either when Emacs has been idle > > for a > > minute, or when you enforce it through completion or other Semantic > > features (like speedbar-analysis). > > > > So the only advice I can give you is to give Emacs some time until > > it > > has parsed most of your headers. If you encounter a completion which > > *always* takes several seconds until it appears, please post an > > example > > here. > > > > -David > > > > ------------------------------------------------------------------------------ > > Download new Adobe(R) Flash(R) Builder(TM) 4 > > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > > Flex(R) Builder(TM)) enable the development of rich applications > > that run > > across multiple browsers and platforms. Download your free trials > > today! > > http://p.sf.net/sfu/adobe-dev2dev > > _______________________________________________ > > Cedet-devel mailing list > > Cedet-devel@... > > https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ Cedet-devel mailing list Cedet-devel@... https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: David Schroeder <medgno@me...> - 2010-10-17 17:26 I'll give that a shot as soon as I figure out how to do that on OS X. However, when I'm waiting for the completions, Emacs is using 100% CPU. I'll also try to put together an as-minimal-as-possible test case. On Oct 17, 2010, at 11:17 AM, Christopher Barry <christopher.barry@...> wrote: > Just a thought, but have you considered trying running the db from a > tmpfs? This would eliminate any disk-based latencies in your analysis. > > -C > > On Sun, 2010-10-17 at 11:01 -0500, David Schroeder wrote: >> I gave my emacs a good amount of time to finish parsing everything, >> letting it run overnight. Still, the first time I ask for a >> completion, I need to wait at least ten seconds, and sometimes >> longer. If I immediately ask for the same completion, it's instant. >> However, if I ask for a different completion and then the first one, >> I still have the same length wait. >> >> My semanticdb folder is 11M, and one of the files is 2.7M large. Is >> this larger than semantic is able to handle well? >> >> >> >> >> On Oct 17, 2010, at 3:05 AM, David Engster <deng@...> >> wrote: >> >> >> >>> David Schroeder writes: >>>> 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. >>> >>> Does it really always take ~10s? It may very well take that long the >>> first time you query the analyzer on a certain class, but subsequent >>> completions on the same class should be much faster, also between >>> sessions. Emacs caches all the semantic information from headers it >>> has >>> parsed to disc (by default in ~/.semanticdb). The first parsing of >>> those >>> headers can be time consuming for a large codebase; for instance, >>> parsing (most of) the STL takes maybe 1-2 minutes on my slow >>> notebook. CEDET will start parsing either when Emacs has been idle >>> for a >>> minute, or when you enforce it through completion or other Semantic >>> features (like speedbar-analysis). >>> >>> So the only advice I can give you is to give Emacs some time until >>> it >>> has parsed most of your headers. If you encounter a completion which >>> *always* takes several seconds until it appears, please post an >>> example >>> here. >>> >>> -David >>> >>> ------------------------------------------------------------------------------ >>> Download new Adobe(R) Flash(R) Builder(TM) 4 >>> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly >>> Flex(R) Builder(TM)) enable the development of rich applications >>> that run >>> across multiple browsers and platforms. Download your free trials >>> today! >>> http://p.sf.net/sfu/adobe-dev2dev >>> _______________________________________________ >>> Cedet-devel mailing list >>> Cedet-devel@... >>> https://lists.sourceforge.net/lists/listinfo/cedet-devel >>> >> ------------------------------------------------------------------------------ >> Download new Adobe(R) Flash(R) Builder(TM) 4 >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly >> Flex(R) Builder(TM)) enable the development of rich applications that run >> across multiple browsers and platforms. Download your free trials today! >> http://p.sf.net/sfu/adobe-dev2dev >> _______________________________________________ Cedet-devel mailing list Cedet-devel@... https://lists.sourceforge.net/lists/listinfo/cedet-devel > > > > ------------------------------------------------------------------------------ > Download new Adobe(R) Flash(R) Builder(TM) 4 > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly > Flex(R) Builder(TM)) enable the development of rich applications that run > across multiple browsers and platforms. Download your free trials today! > http://p.sf.net/sfu/adobe-dev2dev > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: David Engster <deng@ra...> - 2010-10-17 17:54 David Schroeder writes: > I gave my emacs a good amount of time to finish parsing everything, > letting it run overnight. Still, the first time I ask for a > completion, I need to wait at least ten seconds, and sometimes longer. > If I immediately ask for the same completion, it's instant. However, > if I ask for a different completion and then the first one, I still > have the same length wait. > > My semanticdb folder is 11M, and one of the files is 2.7M large. Is > this larger than semantic is able to handle well? This surely is large. I took a look at the G3D library, and there are some header files which are daunting. For example, there's GLG3D/GL/glew.h, which has almost 6000 #defines and 1600 typedefs. And glew.c looks almost worse. Could you give an actual example of what you're trying to complete? Maybe we can make Semantic ignore some stuff you don't really need. -David

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: David Engster <deng@ra...> - 2010-10-17 21:21 [adding the mailing list back to CC; hope that's OK] David Schroeder writes: > There are many files I'd be perfectly happy to have semantic ignore > entirely. I've looked through info and I've not found an obvious way > to set certain files to be excluded (or to set a regexp to be > excluded). I saw that ede-cpp-root-project takes > :header-match-regexp, but that seems like it would be a difficult way > to go about this. If someone could give me a hint in the right > direction, I'd appreciate it greatly. I think you're right that there's no easy way to exclude certain files from parsing. The only way I know of is to hack `semantic--before-fetch-tags-hook' to return nil for certain files. For instance: (defvar my-not-parsed-files-regexps '("glew\\.h$" "glext\\.h$")) (defun my-exclude-files-from-parsing () (not (delq nil (mapcar (lambda (file) (string-match file (buffer-file-name (current-buffer)))) my-not-parsed-files-regexps)))) (add-hook 'semantic--before-fetch-tags-hook 'my-exclude-files-from-parsing) -David

Re: [CEDET-devel] On large project, CEDET analysis takes ~10s From: Eric M. Ludlam <eric@si...> - 2010-10-19 02:14 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

1 message has been excluded from this view by a project administrator.