2编译出来速度怎么样，如果提升不明显，那折腾就没意义了
comp-speed3目前只有tco。
不是说还有把一些函数从funcall变成direct call吗
明显，作者发的benchmark就是用comp-speed=2的Emacs和comp-speed=3的benchmark代码测试的。 都是用native benchmark的情况下native的Emacs和普通Emacs好像区别不大
Column explanation:
-
byte-codebenchmark running byte compiled (baseline). -
native-benchbenchmark running native compiled on a non native compiled emacs. -
native-allbenchmark running with the benchmark itself and all emacs lisp native compiled.
All benchmarks has been compiled with comp-speed 3 while the Emacs lisp for the native-all column with comp-speed 2.
这段话意思是，benchmark函数用速度3，其他用速度2，为了加快benchmark函数的速度，消除其对评测速度的影响吗？
估计是因为Emacs本体用comp-speed=3会挂。
bubble这些用来benchmark的code都用了3；naive-bench用的emacs是非naive compile的（speed 0？否则怎么识别那些naive compile的benchmark？）naive-all的emacs（所有lisp）都是naive compile的。所以只要关键代码speed 3编译，效果也不错
这样的话编译时间和master分支相比差距还大吗？另外，离完全实用还有哪些问题需要解决？
还需要大量小白鼠踩坑以发现哪里会出问题。
作者提到他下一步要集中精力在编译动态作用域代码里，据我所知，Emacs内核本身还有1/4代码在动态作用域下。
另外，我觉得还需要编译cl-generic产生的分发函数，该函数依赖于动态拼接代码（因为他们没给VM加上虚函数分发的字节码），因此native compiler暂时无法优化（不过我总觉得这是JIT的范畴了）
无论如何，比master慢
无native comp = ELC
有native comp = ELC + ELN
native comp使用byte compile后的代码作为输入
了解了，慢慢来嘛。现在值得折腾一波了吗？我看到作者提到他一直用speed 2，觉得挺稳定的。
现在编译之后会有明显的性能提升吗？
我编译了一下，没感觉有明显的性能提升啊。头回用，有不少功能还出了问题。不知道是不是哪里没注意到。到处出现failed to provide feature和Symbol’s function definition is void的问题。
不知道编译速度上有多大提升。我总共用了三个小时。libgccjit一个小时，emacs用两个小时。speed 2。用的是https://aur.archlinux.org/packages/libgccjit/。没改PKGBUILD。
(native-comp-async “~/.emacs.d/elpa” 2 t) 把第三方包也编译下试试。 没用过，如果比较快反馈下哈。
连orgmode都挂了。怎么感觉基本功能都挂掉了？是我哪儿搞错了？
是要把elpa里面所有的包都编译一遍才能正常使用？
现在函数应该是 native-compile-async
1 个赞
@fengche 我没有全部编译，直接打开(setq comp-deferred-compilation t)。这样用起来就正常一些了，不过还是有很多小问题。一下子还没办法正常使用了。呃。 真折腾。
启动速度确实有提升。其他功能还没进一步试用，所以不好说。
出现了很多下面这类错误。
apply: Loading file /usr/share/emacs/28.0.50/lisp/mail/eln-x86_64-pc-linux-gnu-6d32bf10d46bb4cc/rmail.eln failed to provide feature ‘rmail’
elpa下面的可以删除之后重新编译，emacs下面的重新编译会报权限问题，因为编译之后没有root编限写入。这种问题不知道怎么解决？