有没有觉得 spacemacs 移动光标很慢，因为 gc 阈值设置的太大了。我一直被这个问题所困扰，然后今天发现了非常有趣的一贴：
http://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/
然而帖子里的方法对我来说并没有效果，不知道是什么情况 
每次看见优化 emacs 的帖子都非常激动，然后不久就被泼了冷水 ……
1 个赞
光标移动慢和 GC 基本没有关系，而是因为字体等原因图形界面重新绘制慢导致的。这么说吧，就 Emacs 这点运行强度，除了启动意外，其它情况下 GC 都是感觉不出的
有没有什么好的解决办法
关行号，换字体，切长行，拆大文件
1 个赞
光标移动慢主要要检查各种 hook, 有写插件的 hook 写的比较暴力, 如果 hook 以后运行大计算的插件代码,就会超级慢.
2 个赞
第一条，用了原生行号还是慢吗？
后面三条多数条件下并不可行，不是说不管用，是条件所限不可行
你指的是 post-command-hook 吗？这个不容易检查啊，太多包向这个 hook 里添加东西了，有没有什么线索？比如已知哪些包明显会造成拖慢？
evil，company 这些明显都不是善茬啊
我告诉你个笨办法， 用二分注释法。
把你 ~/.emacs 的东西先注释一半， 启动测试一下， 没有问题注释另外一半， 有问题再注释有问题的这部分的一半， 直到定位某一个插件的问题后， 然后用正则表达式搜索所有关于这个插件的 hook 变量，一会就可以弄清楚。
这也是我不建议大家用 Spacemacs 这种大而全的东西，自己用的，看到好的插件一点一点的集成就好，也稳定，要不是出了问题，各种瞎折腾，浪费自己的时间。
1 个赞
多谢建议，不过还是不折腾了，问题不是很严重，主要是 Windows 下的问题，linux 下同样配置溜得多。作为 spacemacs 多年老用户，放弃它不是一个可选项。
即使 spacemacs 也可以用二分注释法找到问题，然后给 spacemacs 的开发者报准确的bug.
要不多不爽啊， 移动光标都慢。
移动光标和输入字符是最不能忍延迟的操作，我就是因为太卡抛弃spacemacs的。Mac上Emacs性能没有Linux上好，我感觉。
搜了一圈，最终把行号关了，把spaceline换成doom-modeline，感觉好多了
一个月之前有一个 commit 说是 pbcopy 可能导致输入卡顿： 386a8f，把 pbcopy 禁用了
你可以更新到最新的 develop 试试
我一直都是最新 
刚好这两天 reddit 也有帖子讨论 emacs 为什么在 Windows 上这么慢，现任维护者 Eli 也参与了讨论，值得一看：
看来不是 spacemacs 的锅，是 windows系统的锅。尽量减少 I/O （比如禁用 spaceline）效果会比较明显
the linux kernel and file systems are optimized for reading/writing many tiny files as well as starting/stopping many short-lived processes (e.g. unix piping). this is the complete opposite of windows, which prefers larger files and long running processes.
this is why WSL, while decent, still doesn’t hold a candle to virtualbox – the filesystem is still backed by NTFS.
git on windows is another prime example of being orders of magnitude slower than linux. add to the fact that magit makes many git process calls and it becomes literally unusable for any non-trivial repository.
my work computer is windows. i run emacs on a remote linux machine and remote the display back to my windows box using Xming. yes…there’s a 200ms input lag, which i would gladly pay for 100ms git statuses vs 5 seconds. if you ran virtualbox locally, there would be no lag.
说的都是猜测，我觉得首先抛出git-for-windows的慢来说，整体的emacs在windows上的反应并不lagging啊，而且现在都普遍ssd（尽管我还是用机械），文件系统间比较的话的话，ntfs真的那么差？
不过spaceline这个是真的坑。
以我自身的感受来说，真的那么差 ，没有试过 ssd 是否更好
还是老老实实用 Linux 吧, 看你发帖, 在Windows下折腾Emacs比我Mac还折腾. 
我终于明白了你为什么那么折腾pdump版本，向emax大大添版本那种‘’求种若渴‘’的原因了 原来也一直用机械 
。
唉，真的是，说多了都是泪
不过还有另外一个原因，折腾 pdump 这种是因为更容易把自己的配置推广给别人。只要拷贝就行了，不用安装那么多包，尤其是网络不畅，原因你懂的。