同样的配置在 Linux 下启动需要 12s，在Windows 下（emacs for Windows 64）却需要这么长时间。有遇到相同问题的朋友吗？怎么解决的？
先不说windows的问题，你的配置在linux上也太慢了……尽量能autoload都autoload
我也一直好奇为什么大家都在 10s 以内，今天终于找到原因了
我习惯把 scratch 设为 emacs-lisp-mode，然后启动时会加载 elisp-mode 以及 yasnippet 的所有 snippet，不慢才怪了！！
真没想到 scratch 是最先启动的，所以 spacemacs 用户没事别改这个设置
Edit:
在 windows 上用 dumper 好多了：
我这还是机械硬盘，要是 SSD 的话估计 1s 以内
1 个赞
我现在可以转到 Windows 平台了，基本问题都解决了，除了 magit 慢这个无解之外，其它和 Linux 相差无几了。
看到有人直接在给 magit 提 issue 时出 1000 英镑 offer，magit 作者说无解，拒绝了这个 offer 
magit 真的是 emacs 上的旗舰应用啊
scratch buffer默认应该是elisp-interactive-mode之类的，具体名字我忘了
我的在windwos 10 1803 x64上面也是10s之外了。
相同的配置在windows 7下面只在4s之内。
大概有10s的时间停在了这里：
我也有同样的问题，我用的 Windows 8.1。而且包越多，这个问题越严重。所以我换 emacs dump 了，现在启动时间 2 点几秒。也可以用 emacs server。
spacemacs 上默认 text-mode
包一多就不行了
一个mode的所有snippet reload一下最多也就5s吧，还是无法解释你这个140s怎么来的。。
问题是启动以后再也不关了，所以对我来说启动时间不那么重要。
1 个赞
推迟 yasnippet 启动以获得漂亮的启动时间，有点自欺欺人。
尝试过在 idle 加载 yasnippet，但我通常在启动 emacs 之后就立刻打字，此后一直没等到足够的空闲时间来启动 yasnippet。往往是当我结束短暂思考的时候，idle 计时到了，然后我再次打字的时候卡住了。
为了使 idle 机制正常发挥作用，我可能需要在 $ emacs -nw 回车之后，去泡一杯咖啡，然后回来很满意地看看启动时间。
也试过在首次 tab 的时候加载 yasnippet，仍然避免不了要暂停输入一段时间。
耗时的 package 无论何时加载，用户都会感受明显，除非异步加载。通用的工具类型的 package，一次性全部加载，多几秒又何妨。特定用途的 package 才考虑按需加载。
Windows 进程开销本来就比较大了，8.1 之后变本加厉？
1 个赞
是有点自欺欺人，不过 3s 以下还是爽 ，而且 defer 之后感觉不那么明显了。spacemacs 那个启动进度条卡在那不动实在是无法忍受 
哈哈，今天我把这个锅给坚果云的“文件保护锁”功能。
80%的可能是它了，还要更多测试。
求分享windows下的spacemacs配置，windows下的python编辑，很蛋疼:joy: