Question

I use CEDET (latest CVS) with several moderately large projects (a few hundred kLOCs each, mostly C, but some C++) and sometimes experience long pauses in which the system is completely unresponsive for seconds. More rarely, it spins out of control completely and I have to mash on C-g and try to move the cursor or switch to a different buffer to get control back.

I use GNU Global to create tags for the projects I work with, but this is still sometimes slow, especially for semantic-symref-symbol, and some jumps that seem to require parsing lots of headers and source files. In some cases semantic-ia-fast-jump errors with the message semantic-ia--fast-jump-helper: Tag SomeFunction has no buffer information even though gtags-find-tag finds it immediately (in the same project), though perhaps at an out-of-date location; this may be a temporary bug, usually semantic-ia-fast-jump is reliable.

I would appreciate any suggestions on how to

• Throttle CEDET without losing all the semantic analysis.
• Find out what caused CEDET to spin out of control so I can fix my project definitions or file a bug report.
• Determine why some semantic analysis is failing.
• Get semantic to cache more information to make it more responsive, I have lots of memory that I’d like to use.
• Manage GNU Global (create and keep current) for multiple projects in different places, including system directories.
• Manage dependencies between projects that I have configured with ede-cpp-root-project.
• Manage projects that have multiple build configurations, each with its own “config.h” and build directory.

There are a few tips in the article http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html, I’m looking for anything beyond that article.

Answer 1

The CEDET tools you are using are limited by Emacs’ ability to track every symbol in your entire project. A good starting point for throttling what CEDET/Semantic does is via semanticdb-find-default-throttle. If you know how your project is organized, you can disable some kinds of searches to speed things up.

CEDET will parse lots of files it thinks you might need which will fill up memory also. In that case you can customize semantic-idle-scheduler-max-buffer-size to disable parsing big files, semantic-idle-work-parse-neighboring-files-flag to disable parsing random nearby stuff, and `semantic-idle-work-update-headers-flag’ to disable parsing headers. Note that the last 2 default to nil, but are enabled by some of the auto-setup functions.

CEDET/Semantic will cache a lot of data in memory, and builds up sorted search tables to boost performance. If you find you are editing header files a lot, those edits cause the caches to go out of date and force them to rebuild. If you exit and restart Emacs a lot, then that forces Semantic to reload large database tables.

Another possibility is to set semanticdb-persistent-path to list only directories that you care a lot about. This will cut back on saved data, which won’t reload. If it is needed, it will reparse as needed, but it will help keep the total data down.

You can also use semantic--before-fetch-tags-hook to a function that returns nil under various conditions. Find files that take a long time to parse due to size, network latency, or whatever, and set them up to never parse. That too will save some time.

Using GNU Global is a good way to speed things up. Using it with semantic symref will cause the files it finds hits in to parse to provide the requesite data for the output display. There isn’t much to do about that.

For the error you found above, if you can identify a way to reproduce it, please share it on the cedet-devel mailing list so it can get fixed. That type of bug has shown up before, usually when the GNU Global tag fails to convert to a buffer tag.

To debug CEDET spinning out of control, use semantic-debug-idle-function and semantic-debug-idle-work-function to narrow things down. See above about some configuration there.

You can use cedet-gnu-global-create/update-database to update a database, or add that to a hook. I don’t think that made it into the doc yet.

Project management is tricky. Most built-in projects are good for small stuff. Particularly large projects with custom build systems usually warrant a custom EDE project type. Creating new projects isn’t too bad. If you look in ede-linux or ede-emacs you can catch the basics. In your custom project, you can wrap up all your related projects, and override features such as macros, include directories and compile commands. I had to write a custom project for my job also. It was very similar to ede-linux with stuff unique to where I work.