CEDET 可扩展性技巧
我将 CEDET（最新的 CVS）用于几个中等规模的项目（每个项目有几百 kLOC，大部分是 C，但也有一些 C++），有时会遇到长时间的暂停，系统在几秒钟内完全没有响应。更罕见的是，它完全失去控制，我必须混搭 Cg 并尝试移动光标或切换到不同的缓冲区才能恢复控制。
我使用 GNU Global 为我使用的项目创建标签，但这有时仍然很慢，特别是对于semantic-symref-symbol，以及一些似乎需要解析大量标头和源文件的跳转。在某些情况下，semantic-ia-fast-jump 错误，并显示消息 semantic-ia--fast-jump-helper: Tag SomeFunction has no buffer information，即使 gtags-find-tag 立即找到它（在同一个项目中），尽管可能位于过时的位置；这可能是一个暂时的错误，通常semantic-ia-fast-jump是可靠的。
任何建议，我将不胜感激
- 对于如何在不丢失所有语义分析的情况下限制 CEDET 的
- 。找出导致 CEDET 失控的原因，以便我可以修复项目定义或提交错误报告。
- 确定某些语义分析失败的原因。
- 获取语义来缓存更多信息以使其更具响应性，我有大量内存需要使用。
- 管理不同位置的多个项目的 GNU Global（创建并保持最新），包括系统目录。
- 管理我使用
ede-cpp-root-project配置的项目之间的依赖关系。 - 管理具有多个构建配置的项目，每个配置都有自己的“config.h”和构建目录。
文章中有一些提示 http://alexott.net/en/writings /emacs-devenv/EmacsCedet.html，我正在寻找除该文章之外的任何内容。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您使用的 CEDET 工具受到 Emacs 跟踪整个项目中每个符号的能力的限制。限制 CEDET/Semantic 功能的一个很好的起点是通过semanticdb-find-default-throttle。如果您知道项目的组织方式，则可以禁用某些类型的搜索以加快速度。
CEDET 将解析它认为您可能需要的大量文件，这也会填满内存。在这种情况下，您可以自定义
semantic-idle-scheduler-max-buffer-size以禁用解析大文件，semantic-idle-work-parse-neighboring-files-flag禁用解析附近的随机内容，并使用“semantic-idle-work-update-headers-flag”禁用解析标头。请注意，最后 2 个默认为零，但由某些自动设置功能启用。CEDET/Semantic 将在内存中缓存大量数据，并构建排序搜索表以提高性能。如果您发现经常编辑头文件，这些编辑会导致缓存过期并强制它们重建。如果您多次退出并重新启动 Emacs，则会强制 Semantic 重新加载大型数据库表。
另一种可能性是设置
semanticdb-persistent-path以仅列出您非常关心的目录。这将减少保存的数据，并且不会重新加载。如果需要，它将根据需要重新解析，但这将有助于减少总数据量。您还可以将
semantic--before-fetch-tags-hook用于在各种条件下返回 nil 的函数。查找由于大小、网络延迟或其他原因而需要很长时间解析的文件，并将它们设置为从不解析。这也将节省一些时间。使用 GNU Global 是加快速度的好方法。将其与语义 symref 一起使用将导致它找到的文件进行解析，以提供输出显示所需的数据。对此没什么可做的。
对于您在上面发现的错误，如果您能找到重现该错误的方法，请在 cedet-devel 邮件列表上分享，以便修复该错误。此类错误以前曾出现过，通常是在 GNU 全局标记无法转换为缓冲区标记时出现。
要调试失控的 CEDET，请使用
semantic-debug-idle-function和semantic-debug-idle-work-function来缩小范围。请参阅上面的一些配置。您可以使用 cedet-gnu-global-create/update-database 来更新数据库，或将其添加到挂钩中。我认为这还没有进入文档。
项目管理很棘手。大多数内置项目都适合小东西。具有自定义构建系统的特别大型项目通常需要自定义 EDE 项目类型。创建新项目并不是太糟糕。如果您查看 ede-linux 或 ede-emacs，您可以了解基础知识。在您的自定义项目中，您可以打包所有相关项目，并覆盖宏、包含目录和编译命令等功能。我还必须为我的工作编写一个自定义项目。它与 ede-linux 非常相似，具有我工作的地方特有的东西。
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-sizeto disable parsing big files,semantic-idle-work-parse-neighboring-files-flagto 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-pathto 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-hookto 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-functionandsemantic-debug-idle-work-functionto narrow things down. See above about some configuration there.You can use
cedet-gnu-global-create/update-databaseto 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.