¿Por qué la finalización del código usando CEDET en Emacs es tan lento?

Question

Recientemente probé KDevelop. Busca símbolos (variables, nombres de funciones, clase, estructura ...) mucho más rápido (al instante) que semantic-complete-self-insert o M-Ret. El uso de M-Ret es más rápido, pero no tiene un formato agradable como otros IDEs, en cambio el sin sentido como From nil >. En emacs, debo esperar al menos ~ 1 segundo, en muchos casos, esperando que CEDET busque todos los archivos fuente relacionados incluidos, lo que lleva mucho tiempo.

He usado auto complete clang, pero parece que no tiene una mejora en la velocidad. ¿Por qué es eso :(? Me encanta Emacs y todo, y lo he usado para mi C/C++ durante casi un año hasta que descubro KDevelop, pero usar Emacs significa que la finalización del código debe ser trivial y opcional?

Answer 1

Esta es la respuesta más simple es probable que KDEvelop's DUChain y los analizadores estén escritos en (supongo) C++ con token management similarmente construido. Los analizadores de CEDET están todos en Emacs Lisp, y las bases de datos y búsquedas también están en Emacs Lisp. Mientras que algunas tablas se construyen y almacenan en caché entre llamadas al motor de finalización en Emacs, se reconstruyen con frecuencia a medida que se cambia el código (debido a tipeo) .El motor de finalización CEDET puede ser bastante rápido una vez que todas las tablas están compiladas.

He ejecutado muchas ejecuciones de perfil en la finalización de código para hacer las cosas más rápido, y después de leer un poco sobre duchain, parece que KDevelop tiene una tabla de símbolos maestros para todo el proyecto. CEDET no puede hacer esto, ya que no todos los archivos están en un proyecto, por lo que cada archivo necesita una tabla add-hoc para crear. Lo supe desde hace bastante tiempo, pero nunca llegué a externalizar las bases de datos de símbolos para CEDET, de modo que dichas tablas pudieran construirse y mantenerse en un hilo (proceso) separado.