开发者

Why code completion using CEDET in Emacs so slow?

开发者 https://www.devze.com 2023-04-12 16:00 出处:网络
I recently try KDevelop. It looks up for symbols (variables, function names, class, struct...) much faster (instantly) than s开发者_运维百科emantic-complete-self-insert or M-Ret. Using M-Ret is faster

I recently try KDevelop. It looks up for symbols (variables, function names, class, struct...) much faster (instantly) than s开发者_运维百科emantic-complete-self-insert or M-Ret. Using M-Ret is faster, but it does not have nice format like other IDEs, instead the meaningless one like From nil >. In emacs, I must wait for at least ~1 sec, in many cases, waiting for CEDET to look up all the included related source files, which takes very long.

I used auto complete clang, but it seems to have no speed improvement. Why is that :( ? I love Emacs and all, and been using it for my C/C++ for almost a year until I discover KDevelop, but using Emacs means code completion should be trivial and optional?


This simplest answer is likely that KDevelop's DUChain and parsers are written in (I presume) C++ with token management similarly built. CEDET's parsers are all in Emacs Lisp, and the databases and lookups are also in Emacs Lisp. While some tables are built and cached between calls to the completion engine in Emacs, they are frequently rebuilt as code is changed (due to typing). The CEDET completion engine can be quite fast once all the tables are built.

I have run many profile runs over code completion to make things faster, and after reading a little about duchain, it looks like KDevelop has a master symbol table for the entire project. CEDET can't do this since not all files are in a project, so each file needs an add-hoc table to be created. I've known about that for quite a while, but never gotten to externalizing the symbol databases for CEDET so that such tables could be built and maintained in a separate thread (process).

0

精彩评论

暂无评论...
验证码 换一张
取 消