想学习一下 quickjs，于是用 Emacs 打开，但是，但是，就在此时遇到一个 1.7 MB 的 C 文件，虽打开无压力，但运行 consult-imenu 变得非常卡！打开 eglot ，更是差点卡死掉。关掉 eglot ，用 CTAGS 跳转，速度相对就好多了。
据我观察，导致 imenu 变慢的原因是，每次运行 imenu 时，Emacs 都会重建“大纲”。
我想问的是：1. 有什么方法解决 imenu 慢的问题？2. 遇到这么大的文件，道友们一般是如何处理的，有哪些优雅的办法？3. eglot 的性能还有救吗？谢谢了！
按道理来说，应该可以搞一个缓存机制。在第一次加载完成后，就不必重建索引表。
用的 2015 年版 MacBook Pro，2.2GHz 4 核 i7，16GB RAM，macOS 12 Montery
用 Emacs 29.1 打开 quickjs.c，只体会到 font lock 的轻度卡顿，eglot + 系统自带的 clangd 很快打开，跳转正常工作，没有造成额外卡顿。
我不用 consult，所以直接用 M-x imenu 测的，除了启动 Emacs，打开 eglot 后第一次用 imenu 要等几秒，后面都感觉不到要等待。明显是实现了缓存的
另外，不开 eglot，imenu 本身也有基本的 function index 功能，不到一秒就能打开。
所以这个显然不是普遍现象。
建议，提供更详细的信息
我另外用 i9-11900K 64GB RAM 的 Windows 11 试了下， Emacs 是上几个月编译的 develop 版本，开了 native comp
用 ccls 配合 eglot 用打开 quickjs.c 明显卡了许多。用 Intel oneAPI 帯的 clangd 还是没有明显性能问题。两个 server 都会把光标所在的 token 加粗显示出来，所以应該不是渲染致使的性能问题。
imenu 的话，不管 ccls 还是 clangd，似乎都没有明显区别，打开来还更快了一点，当然可能因为是我硬盘用的 Intel Optane SSD 905P 的关系。
结论，大文件 eglot 不要和 ccls 一起用。是不是 ccls 性能有差就不是我要负则的问题了。据我所知 parser 和 clangd 用的是一样的，可能设计 lsp 界面时对 emacs 这样单线程的应用沒什么优化
consult-imenu 可能优化有问题。imenu 本身应该设计还是正常的。
eglot 本身性能在这种规模上没有大问题，配置好一点硬上完全可以。
consult-imenu 也有缓存，但是文件稍有改动就会重建。
eglot + clangd 刚开始有点卡不过还能用，但过一会儿就卡，不知道为什么。
我用的是 UOS / AArch64 国产 CPU/ SSD / Emacs 29.3 （自己编译的），机器是四年前的，不过硬件性能应该还行。
你看看counsult对imenu的具体实现是怎么样的.emacs自己的imenu默认是正则表达式实现,速度应该还可以.
另外counsel-etags提供了一个基于ctags的imenu实现,速度还可以,你可以参考一下代码.
好的。感谢哥。我看看 consult-imenu 和 counsel-etags 。