deferred compile不错，有助于提高make的速度，make时，只要编译几十个elisp文件，能生成emacs的pdump文件就可以了。不然，每次都要完整编译700多个eln，我的机器在comp-speed = 0 都至少要3个小时。
由于comp-speed=2无法编译, 现在我是用comp-speed=1编译的. 我发现并没有比正常的emacs快啊:
(benchmark-run 1 (directory-files-recursively "~/contrib" "py$"))
普通的emacs: 17.39s
with-nativecomp: 58.22s
能解释为什么嘛?
你这个是系统遍历？是C在做，它加速的是elisp密集的地方吧
不是吧, describe-function显示directory-files-recursively就是一个普通的elisp函数
尝试了一下 feature/native-comp, 发现我这 LaTeX mode 不能用了。
使用 emacs -Q
并设置 debug-on-error 为 t 后，报错如下：
Debugger entered--Lisp error: (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
tex-mode-internal() ;; 这个共有 1591 行
tex-mode()
latex-mode()
funcall-interactively(latex-mode)
call-interactively(latex-mode record nil)
command-execute(latex-mode record)
execute-extended-command(nil "latex-mode" "latex-mode")
funcall-interactively(execute-extended-command nil "latex-mode" "latex-mode")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)
我也遇到了，把latex的eln文件删掉就行
1 个赞
好奇你们是怎么让comp-speed＝2通过的？我编译只能用0才能通过。但是这样编译的emacs速度并没有改善
1 个赞
这个后面会合到主分支吗？还是说只是实验特性？不一定合到master。。。
另外，对于性能提升很好吗？
Me too， speed=2 的情况下，估计机器太差， 我让一台 6g 内存的老平台编译， 到 ielm 那部分下的那个什么ja-* 包（名字记不清了）就是编译不过， 最后就是内存溢出，然后 进程被杀， waiting for job … 之类的。
gccemacs 的作者写了一篇论文，有兴趣的可以看看 https://zenodo.org/record/3736363/files/GCCEMACS_proceeding.pdf?download=1
3 个赞
谢谢分享，早上起来粗略的阅读了一下， 基本的elisp2nativecode的转换机制从这篇pdf中说的很详细了（底层专业知识嵌入的蛮多的，尤其是C的部分和gcc平台的那些东西，很多我看不懂）。原来nativecomp也要和bytecomp一样走LAP的，而且作者也说现在nativecomp主要针对运行速度的提升，对于gc和多线程改动等仍然处于观望状态 。
只不过我的疑惑是他针对的4种bootstrap选项（0 1 2 3） 的 0 和 1 都没有对lisp对象进行优化，那么像在这个帖子里的大家的能成功的编译方式都在采用0 或 1 不是就无法体现出nativecomp的优势了？换句话说，如果不采用comp-speed为2或3 不是就无法产生作者所说的2.3x到42x的运行速度提升了？关键是我看到作者本人在的benchmark 的横向对比就是用的 comp-speed=3。文章种的这句话：
The optimized native-code allows all the benchmarks to run at least two times faster, with most of them reaching much higher performance boosts.
这个 optimized 的语境是否需要comp-speed=2以及以上？
还有就是，他加入的elisp extension支持，也就是那个 comp-hint-fixnum 和 comp-hint-cons 的加持是不是插件编写中的为nativecomp优化的特殊context？ 如果是的话，会用在什么具体的实例中？
就是加type提升优化程度
关于comp-speed，确实如此，我用2以上编译会报错。用0编译出来的emacs速度没提升
手动加的话， 如何规避非native-comp分支的emacs的eval问题，还是自己手动做一个条件判断wrapper？ 再来这不是又会增加插件编译时间 
我试了好几次，也是这样的感觉，但是没做benchmark，因此纯感官体验， 但是我看楼上有一个用0的编译后，感觉很快的，不解，还是我编译方式错了？
等稳定之后进入Emacs主分支就没这问题了
非要用的话
(defmacro my/hint-cons (form)
(if (require 'comp nil t)
`(comp-hint-cons ,form)
,form))
Sou Ka, 我先在自己的配置里试试有没有性能提升。
即使是0，native code也应该比byte code快吧？
可能和机器的配置有些关系。我的整个linux是安装在笔记本的机械硬盘上的，本身就很慢。 排除冷启动的话，变化最明显的就是一些类似posframe的场景，pyim从按下键到出现posframe的时间会比之前短一些。
那 pdump 太适合你了