Dlaczego tworzenie kodu przy użyciu CEDET w Emacs jest tak wolne?

Question

Niedawno próbowałem KDevelop. Wyszukuje symbole (zmienne, nazwy funkcji, klasę, strukturę ...) znacznie szybciej (natychmiastowo) niż semantic-complete-self-insert lub M-Ret. Używanie M-Ret jest szybsze, ale nie ma dobrego formatu, jak inne IDE, zamiast tego bez znaczenia, takiego jak From nil >. W emacsie muszę poczekać co najmniej ~ 1 sekundę, w wielu przypadkach czekać na CEDET, aby wyszukać wszystkie powiązane pliki źródłowe, co zajmuje bardzo dużo czasu.

Użyłem auto complete clang, ale wydaje się, że nie ma poprawy prędkości. Dlaczego :(? Uwielbiam Emacsa i wszystko, i używam go dla mojego C/C++ przez prawie rok, dopóki nie odkryję KDevelop, ale używanie Emacsa oznacza, że ​​uzupełnianie kodu powinno być trywialne i opcjonalne?

Answer 1

Ta najprostsza odpowiedź to: Prawdopodobnie DUChain i parsery KDevelopa są napisane w C++ (podobnie jak C++) z podobnym wbudowanym zarządzaniem tokenami, wszystkie parsery CEDET-a znajdują się w Emacs Lisp, a bazy danych i odnośniki są również w Emacs Lisp. Podczas gdy niektóre tabele są budowane i buforowane między wywołaniami kompletny silnik w Emacsie, są często przebudowywane po zmianie kodu (z powodu pisania) Silnik zakończenia CEDET może być dość szybki, gdy wszystkie tabele zostaną zbudowane

Mam wiele uruchomień profilów nad zakończeniem kodu, aby rzeczy szybciej i po przeczytaniu trochę o duchu, wygląda na to, że KDevelop ma główną tablicę symboli dla całego projektu. CEDET nie może tego zrobić, ponieważ nie wszystkie pliki znajdują się w projekcie, więc każdy plik wymaga utworzenia tabeli add-hoc. Dowiedziałem się o tym od dłuższego czasu, ale nigdy nie udało mi się wyeksponować baz symboli dla CEDET, aby takie tabele mogły być budowane i utrzymywane w osobnym wątku (procesie).