这个report是我提的 
本来想把pdumper搞进我的配置里，但在evil这里卡住了。看来还是高估了现实情况
建议大家去参考一下spacemacs的dumper配置。比较成熟，常见问题都解决了。哪些包有问题已经有人踩过坑了。
我看里面的讨论，100%完美dump配置过的Emacs不在Emacs 27.1的计划里，更完美的支持可能要等Emacs28了。不过只是dump一些包的话，现在完全没有问题。
对没错，完美的pdumper并不在人家的计划里。 不过，他们的计划列表到底是啥样的呢……
如果升级 ivy 或者 company，是不是要全部重新 dump？
dump也就二十秒，很快的
使用了一下，发现一个需要注意的地方，dump的环境跟实际使用的环境可能是不一样的，比如(display-graphic-p)的返回值
看起来值得尝试，不知道提升效果如何。另外，有和native elisp性能对比吗？
没，native目前还不是傻瓜式操作，等进一步整合了再说。
看了下，现在使用 dump还是很简单了，准备试试看。
Update：在 Centaur 中测试了，确实略微有些提升（显示~0.3s左右），观感没什么区别。好处是一些包不需要加载直接使用，第一次也不会有卡顿现象。缺点是如果包升级也得重新 dump，而且启动时得特殊参数。所以和 doom 的结论一样，没有必要切换过去，仍然保留原有方式。
Windows下，忘记是否支持module了；另外有时候会出现奇怪的找不到dll的问题，比如zlib，可以打开zip文件，但是eww碰到某些网站就报找不到zlib的错
auto-dump.el 安排上
这只算增强一点体验吧，仍然是缺点。如果升级包不是需要 dump 的包怎么办？简单粗暴的肯定是全部 dump，要优化还得判断当前安装包在不在 dump list 里。这个包怎么处理的呢？
如果把你口中的 dump 换成编译(.elc)的话，auto-compile.el 完全满足这些要求。
只 dump 成一个文件这点还是有区别的，的确需要都 dump。不过反正装软件包也挺花时间的。
测试了一下，把用到的所有的package都dump了。
时间从4.4s到了0.19s(从early-init.el第一行到init.el最后一行)。
但是这个时间并不是真正的启动时间，在按下快捷键到emacs出现窗口中间，还有个时间。
$ time emacs --dump-file="/home/tianshu/.emacs.d/emacs.pdmp" --eval '(kill-emacs)'
0.77s user 0.08s system 76% cpu 1.109 total
总的时长要1s左右，比emacsclient要长一倍的样子。不过比之前是好了太多了。
1 个赞
以前我在老的小笔记本上用Emacs的时候，包括desktop-save-mode 的session，启动需要3分钟，我都能忍受。现在换到MacBook Pro上，SSD的速度让我已经很快了，基本20秒不到。什么都没做。应该能更快，因为我很多文件是放在外置硬盘的，如果也放在SSD上大概会10s左右。我已经觉得超级快了。。。。。。真不知道你们追求的一两秒的提升是在追求什么快感。。。。。
2 个赞
。。。。。
因为最近经常要开多个emacs，每个emacs一个工程，所以启动时间还是有点意义。 当然几秒就已经可以接受了。 但是这个emacs dump的成本不是很高，弄起来不是很麻烦。
可能人家是在用鼠标双击文件 然后用emacs打开