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

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

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


c++ emacs cedet
person Amumu    schedule 12.10.2011    source источник

Ответы (1)


arrow_upward
6
arrow_downward

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

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

person Eric    schedule 20.10.2011