Почему завершение кода с использованием CEDET в Emacs так медленно?

Question

Я недавно попробовал KDevelop.Он ищет символы (переменные, имена функций, класс, структура ...) намного быстрее (мгновенно), чем semantic-complete-self-insert или M-Ret.Использование M-Ret быстрее, но у него нет хорошего формата, как у других IDE, вместо бессмысленного, такого как From nil >.В emacs я должен ждать не менее ~ 1 секунды, во многих случаях, ожидая, пока CEDET найдет все связанные исходные файлы, что занимает очень много времени.

Я использовал auto complete clang, но, похоже, нет улучшения скорости.Почему это так :(? Я люблю Emacs и все, и использую его для своего C / C ++ почти год, пока не обнаружу KDevelop, но использование Emacs означает, что завершение кода должно быть тривиальным и необязательным?

Answer 1

Этот простейший ответ, вероятно, состоит в том, что DUChain и парсеры KDevelop написаны на (я полагаю) C ++ с аналогичным построением управления токенами. Все парсеры CEDET находятся в Emacs Lisp, а базы данных и поиски также находятся в Emacs Lisp. Хотя некоторые таблицы создаются и кэшируются между вызовами механизма завершения в Emacs, они часто перестраиваются при изменении кода (из-за ввода). Механизм завершения CEDET может быть довольно быстрым, когда все таблицы построены.

Я запустил много профилей, выполняющих завершение кода, чтобы ускорить процесс, и, прочитав немного о duchain, похоже, что в KDevelop есть главная таблица символов для всего проекта. CEDET не может этого сделать, поскольку не все файлы находятся в проекте, поэтому для создания каждого файла требуется дополнительная таблица. Я знал об этом довольно давно, но никогда не получал экстернализации баз данных символов для CEDET, чтобы такие таблицы можно было создавать и поддерживать в отдельном потоке (процессе).