这位同学用 Emacs 写了28年 C++ , 总计180万行代码，用来求解微分方程组。 我自己用他写的 exuberant ctags 脚本生成标签后，主要用来看他的代码。
4 个赞
在emacs里调用global -xGqT，发现前后花了0.4秒，这应该是导致卡顿的主要原因
0.4秒很快了。估计还是Lisp代码的问题。更新tags file通常是独立进程，对用户体验没有影响的。Lisp本来就很慢，company代码写得也不好。另外更新tags file应还用了-u选项，所以比0.4秒更快。
我重新看了一遍你的PR，你的意思是说，因为每一次补全时都会重新构建一个lisp列表，这个过程很慢，而导致了卡顿吗？
Yes, Lisp本来就很慢。当初实现的程序员又用了一个最慢的api （该api是用lisp实现的）。我这里谈的是company-etags。 company-gtags我不清楚，不过我猜也没怎么优化过。
我把company-gtags代码看了一下，确实性能上还有很多可改进的余地。
我对company-etags的优化，
启动时间从两分钟降到9秒。查询速度是原来的50倍。根据tags file更新缓存原来也和启动时间差不多，现在1秒搞定。
在Linux Kernel的代码测试过，毫无延迟。
3 个赞
感谢，明天去看代码然后测试一下；
目前pull request 还没被接受。最简单的启用最新代码的方法：
cp company-etags.el /home/cb/.emacs.d/elpa/company-20190430.1852/ && rm /home/cb/.emacs.d/elpa/company-20190430.1852/*.elc
等这个pull request 被接受后，我研究一下company-gtags的优化
2 个赞
哇， 近距离膜拜大神
直接从你fork的项目里把company-etags弄了下来；总而言之效果好得飞起；初始加载变得更快，delay设置为.1也丝毫没有卡顿；
我打算使用counsel-etags来做补全，因为这个速度飞快；
而依然选择用counsel-gtags做代码导航，因为没有find, grep 及类似的工具，试用counsel-etags觉得功能似乎不如counsel-gtags强大；
没人在 Windows 下折腾lsp+ccls 之类的开发 C/C++吗？理论上速度会比 Linux 上慢些，但比一般的基于 tag 的应该要好些。另外，搜索代码肯定用 ripgrep 了，Windows 下速度也很快，基于 rg 的跳转工具 dump-jump 也很好用啊。
company-gtags也可以基于同样的算法改进的。实际上比company-etags还容易点。
counsel-etags唯一强制依赖是ctags其他都是可选的.ctags的精确度肯定不如gtags。
为什么z而不是Z？ (and (>= c ?A) (<= c ?z))
笔误，改了。谢谢。
试了下，现在是不是还不能在远程使用
不能，如果我修正了会在issue tracker里反映的。
dumb-jump，学到一个新技能，谢谢
我是windows，用ccls，流畅的很，补全没有丝毫的卡顿。
company+lsp gcc+clang
才发现我有company-mode的合作者权限，可以批准pull request。负责company-mode的俄国人可能休假去了。我再等一个礼拜就直接批准自己的pull request了。请继续测company-etags，把问题报告给我。
3 个赞