[投票] 你开启 native-compilation 特性了吗？

Emacs-general
41

m1 mac编译emacs还是挺快的也就五分钟吧，我现在还在折腾研究配置中所以想先开着native-comp看看。不过确实可能性能提升未必有多明显。我想的是学习一下懒猫大神的submodule管理方式然后不要频繁更新，这样其实编译应该也就每次折腾配置的时候搞一遍就差不多了吧。

另外还想到一个好处是可能是，引用新的脚本或者插件的时候可以直接编译一下看看有没有什么bug或者缺少依赖，这样不用去运行就可以直接先处理了？（当然elisp可以随便执行的其实直接执行一下也没什么 :smile:）

42

同时检查下其他变量呢，比如：inhibit-automatic-native-compilation

43

inhibit-automatic-native-compilation是nil

其他几个native-comp-always-compile，load-no-native，package-native-compile也都是nil（最后一个应该是指安装的时候是不是编译吧，我直接load lisp的话应该不是这个影响？）

在我的配置folder下面rg了一下native-comp，自己也没有相关的代码。 :sweat_smile:

44

重启 Emacs 才会重新编译eln 的。

45

因为就是想实验他自动触发，所以关闭重启很多次了。elc也都是重新生成的不是以前用28版生成的。

46

你弄个最小化的配置，这样大家也可以试试看，如果能重现问题，可能得向Emacs 报个 BUG了。

我这是可以自动触发的。不过我们是比较烦这个自动触发，所以要关了 :smile:

47

我这里也是可以自动触发的，除非其他地方有影响。用emacs -Q排除下

48

我开了native-compilation，感觉没有任何变化…主要是我不用lsp和其他什么复杂的插件，emacs也是完全在终端使用

./configure --without-x
              --without-xwidgets
              --with-x-toolkit=no
              --with-native-compilation
              --with-json
	      --with-mailutils
	      --with-pop
	      --with-native-compilation
	      --with-gnutls
49

我都不打开native-comp的编译选项，不然还得搭上个libgccjit.so，找不到自动copy依赖的lib的ruby脚本了，而且也不用native-comp。每次更新都得把eln删干净，不然容易出问题。

直接用el文件，速度没什么变化。主要是省事。

3 个赞
50

确实，我遇到过这样的问题。

我也打算先关闭 native-comp 编译选项，先用一段时间看看。

51

这种情况算是开了，说明是能接受 native-comp的。就不分那么细了吧。

52

( @aqua0210 不能同时回复就at一下好了） 我排查出来了，应该是因为我抄了懒猫的auto-save和session自动保存、自动销毁scratch buffer的逻辑。然后这部分不知道为什么在29里面有点问题，经常报访问已经被删除的buffer的错，然后似乎就会阻塞掉其他文件的编译。（也可能是我抄的不对 :stuck_out_tongue_winking_eye:）把这部分去掉以后就正常了。 :rofl:（正好我原本也准备以后这块去掉改成其他模式试试）

顺便再问一下，我没理解错的话手动编译一个文件的时候它依赖的elisp也会被自动编译，但是有些内置的包如果没有被别人依赖的话什么时候编译？具体说的话，你们会先手动把比如 /opt/homebrew/Cellar/emacs-plus@29/29.0.60/share/emacs/29.0.60/lisp 这里的包先编译一遍么？

折腾了一通我也有点感觉这编译体验有点烦人了 :rofl: 像你们说的，尤其电脑配置还可以的话这点执行效率可能真的没差太多，但是更新和debug这块确实比较麻烦。如果体验能像隔壁neovim的luajit那样顺手一点就好了（

53

期待你的反馈。我一直是默认用naive-comp，平时用很多的evil和lsp，看楼上前辈说，evil可能会有提升。不知道你是否是evil的用户。

54

我是 Emacs 原生按键用户，不用 evil :smile:

我现在不用 native-comp，感觉整体的使用很流畅，LSP 也是。不过我暂时没用大型的项目。

在 Reddit 一个关于 Emacs 性能提升方面的讨论 (2022年2月) 可以看出，为什么很多人安装了 Emacs 28 或者 Emacs 29 后即使没有开 native-comp 也能感觉到明显的性能提升。

因为开发者对 Emacs 在以下方面做了优化：

And more; Mattias Engdegård is doing some nice work.

当然，这些优化对开了 native-comp 也有效果。

详细可以看这个链接：https://www.reddit.com/r/emacs/comments/sunkzx/is_it_only_me_or_did_emacs_without_native_comp/

3 个赞
55

内置的包加载的时候会自动编译，第三方包安装的时候会自动编译（其实也是加载时，安装完成会自动加载）。内置的包用 aot选项编译就会在build时一次性native-comp好。

如果体验相差不大，第三方包安装不必启用native-comp，甚至完全关闭都是没问题的，尤其是29+。

3 个赞
56

忽然发现homebrew-emacs-plus提供的native-comp选项似乎没有开启AOT参数？看到他之前的pr自己给close了，好像是因为加了以后emacs编译时间翻倍了 :sweat_smile:

57

开启 native-comp 有没有提升快要成玄学了。

3 个赞
58

试试 GitHub - daviderestivo/homebrew-emacs-head: GNU Emacs formula for the Homebrew package manager

1 个赞
59

估计和 Ruby 的 MJIT 一样，跑分很厉害，实际提升约等于无

在 talk 中，Maxime 提到了为什么 MJIT 在很多时候失效：

  1. MJIT 优化的 benchmark 和实际场景差别太远；
  2. gcc 本质上还是针对静态语言 的编译器，你不能指望在不怎么做 specification 或者 type analysis 的情况下，单纯把字节码转成 C，gcc 就能帮你做优化。
2 个赞
60

emacs-head, 编译时开启了aot，反正只需编译一次。其余的第三方包不用native-comp，我觉得懒猫说的很有道理，elisp真正的瓶颈是无法通过native-comp进行改善的，是否开启聊胜于无。像多线程这些就应该靠外部成熟的轮子解决，不要有洁癖，限定elisp和c。

1 个赞