编译 Erlang 时有哪些限制/约束 .erl来源 +native选项与通常的“非本地”编译相比？
相关:Erlang OTP release compiles with HiPE?
最佳答案
BEAM 仿真器提供的跟踪、断点和单步执行功能在 native 编译代码中不可用。还有一个限制是，当您加载同一模块的较新版本时， native 代码并没有真正从内存中卸载。 (如果您有一个长时间运行的系统，您不断升级模块或动态生成和编译模块，这可能是一个问题。)
此外，在 native 代码和仿真 BEAM 代码之间跳转时会有少量开销，因此您应该避免在速度很重要的紧密循环中进行这种模式切换。最好将所有密切相关的模块编译为 native ，如果可能的话也编译最重要的标准库模块。
最后，虽然原生编译器经过了很好的测试，但 HiPE 中出现编译器错误的概率比 BEAM 仿真器 C 代码中的错误要高一些(尽管可能不高于 GCC 中的错误)，所以你可以运行系统段错误的风险更大。不过，这几天很少见了。
总而言之，目前可能不建议使用原生编译的主要地方是独立产品(例如您交付给客户的黑盒服务器)，其中稳定性、远程可调试性和低内存使用率是您的主要目标关注和计算速度通常不是。
关于erlang - 使用 "+native"编译的约束/限制是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2207481/