Rust Glancer, un servidor LSP funcional para Rust, usa dos órdenes de magnitud menos RAM que rust-analyzer. El autor critica la dependencia de rust-analyzer en [PERSON_NAME] para árboles de sintaxis y sugiere que para el caso de uso del 99% —analizar 6666 dependencias que nunca editas— una simple lista de arrays sería suficiente. El análisis incremental y las refactorizaciones por mutación del DOM solo son necesarias para el 1% activamente editado.

Los macros de procedimiento siguen siendo un gran consumidor de memoria: expandirlos ejecuta código real, genera una salida masiva y contribuye ~30% del tamaño del binario de rust-analyzer mediante análisis JSON. Un enfoque perezoso y no incremental para cuerpos de funciones —indexando solo elementos y analizando el archivo actual— podría combinar lo mejor de ambos mundos. La comparación con Rust Rover (sin GUI) sugiere una compacidad similar, aunque el soporte para build-scripts y proc-macros puede permanecer limitado.

La arquitectura ideal refleja el PSI de IntelliJ: un árbol de sintaxis concreto para archivos abiertos, un árbol de stubs compacto en disco para archivos del proyecto, y archivos .rmeta precompilados para dependencias. [PERSON_NAME] debería cambiar a salsa solo cuando el usuario toque ~/.cargo/registry/src. Definir una API abstracta para acceso a código Rust —con soporte para entradas rmeta— sigue siendo la fruta más baja para un verdadero "analizador de vistazo".

Entidades clave: Empresas: [PERSON_NAME], rust-analyzer, Rust Rover, IntelliJ, Dart Analyzer | Personas: [PERSON_NAME]