CEDET可扩展性提示

Question

我使用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是可靠的.

我很感激有关如何做的任何建议

• 节流CEDET而不会失去所有的语义分析.
• 找出导致CEDET失控的原因,以便我可以修复我的项目定义或提交错误报告.
• 确定某些语义分析失败的原因.
• 获取语​​义来缓存更多信息以使其更具响应性,我有很多内存,我想使用它.
• 管理不同位置(包括系统目录)中的多个项目的GNU Global(创建并保持最新).
• 管理我已配置的项目之间的依赖关系ede-cpp-root-project.
• 管理具有多个构建配置的项目,每个构建配置都有自己的"config.h"和构建目录.

文章http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html中有一些提示,我正在寻找除该文章之外的任何内容.

Answer 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个默认为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非常相似,具有我工作的独特之处.