为什么在Emacs中使用CEDET进行代码补全如此缓慢？

Question

为什么在Emacs中使用CEDET进行代码补全如此缓慢？

7

我最近尝试了KDevelop。它查找符号（变量、函数名、类、结构体等）比semantic-complete-self-insert或M-Ret快得多（瞬间完成）。使用M-Ret更快，但它没有像其他IDE那样漂亮的格式，而是像From nil >这样毫无意义的格式。在Emacs中，我必须等待至少1秒钟，在许多情况下，需要等待CEDET查找所有包含的相关源文件，这需要很长时间。

我使用auto complete clang，但似乎没有速度提升。为什么呢:(？我喜欢Emacs，并且一直在使用它来进行C/C++编程，但是使用Emacs意味着代码补全应该是微不足道和可选的吗？

- Amumu

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eric · Accepted Answer

这个问题的简单答案可能是KDevelop的DUChain和解析器采用C++编写，具有类似的标记管理。CEDET的解析器都是用Emacs Lisp编写的，数据库和查找也是用Emacs Lisp编写的。在Emacs中，虽然有些表格是在调用完成引擎之间构建和缓存的，但随着代码的更改（由于输入），它们经常被重新构建。一旦所有表格都被构建完毕，CEDET完成引擎可以非常快。

我运行了许多代码完成的性能分析，为了使事情更快，读了一些关于duchain的文章，看起来KDevelop对整个项目有一个主符号表。CEDET无法做到这一点，因为并非所有文件都在一个项目中，所以需要为每个文件创建一个特定的表格。我已经知道这个问题很久了，但从未将符号数据库外部化，以便可以在单独的线程（进程）中构建和维护这样的表格。