我使用CEDET（最新的CVS）和几个中等规模的项目（每个几百个kLOC，主要是C，但是一些C ++），有时会遇到长时间暂停，系统几秒钟内完全没有响应。更少见的是，它完全失控，我必须在C-g上进行混搭并尝试移动光标或切换到不同的缓冲区以获得控制权。
我使用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是可靠的。
我很感激有关如何
的任何建议ede-cpp-root-project配置的项目之间的依赖关系。文章http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html中有一些提示，我正在寻找除该文章之外的任何内容。
答案 0 :(得分：20)
您正在使用的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个默认为nil，但是由某些自动设置功能启用。
CEDET / Semantic将在内存中缓存大量数据，并构建排序的搜索表以提高性能。如果您发现编辑头文件很多，那些编辑会导致缓存过时并强制重建。如果您退出并重新启动Emacs，那么会强制Semantic重新加载大型数据库表。
另一种可能性是将semanticdb-persistent-path设置为仅列出您非常关心的目录。这将减少保存的数据，不会重新加载。如果需要，它将根据需要重新分析，但它将有助于保持总数据下降。
您还可以将semantic--before-fetch-tags-hook用于在各种条件下返回nil的函数。查找由于大小，网络延迟等原因需要很长时间才能解析的文件，并将它们设置为永不解析。这也将节省一些时间。
使用GNU Global是加快速度的好方法。将它与语义symref一起使用将导致它找到的文件进行解析，以便为输出显示提供请求数据。关于那个没什么可做的。
对于您在上面找到的错误，如果您可以找到重现它的方法，请在cedet-devel邮件列表上分享，以便修复它。之前出现过这种类型的错误，通常是在GNU Global标记无法转换为缓冲区标记时。
要调试CEDET失控，请使用semantic-debug-idle-function和semantic-debug-idle-work-function缩小范围。请参阅上面的一些配置。
您可以使用cedet-gnu-global-create/update-database更新数据库，或将其添加到数据库。我认为这还没有成为文档。
项目管理很棘手。大多数内置项目都适合小东西。具有自定义构建系统的特别大型项目通常需要自定义EDE项目类型。创建新项目也不算太糟糕。如果您查看ede-linux或ede-emacs，您可以了解基础知识。在自定义项目中，您可以包装所有相关项目，并覆盖宏，包含目录和编译命令等功能。我也必须为我的工作写一个自定义项目。它与ede-linux非常相似，具有我工作的独特之处。