这个关于Erlang可扩展性的post表示每次调用，转换或发送给gen_server的消息都会产生开销。它有多少开销，它有什么用？
答案 0 :(得分：6)
引用的成本是对外部模块的（相对盲目）函数调用的成本。发生这种情况是因为gen_ *抽象中的所有内容都是对外部定义函数（您在回调模块中编写的函数）的回调，而不是编译器可以在单个模块中优化的函数调用。这个成本的一部分是调用的解析（找到正确的代码来执行 - 同样的原因，在Python或Java中的每个“dot”in.a.long.function.or.method.call都提高了解决的成本）另一部分成本是实际的呼叫本身。
<强> BUT
这不是您可以计算的简单数量，然后乘以获得有关整个系统运营成本的有意义答案。
在像Erlang这样大规模并发系统中有太多变量，约束点和意外的廉价元素，其中并发的最难部分被抽象出来（调度相关问题）并且最昂贵的并行处理元素变得非常便宜（上下文切换，进程生成/终止和进程：内存比率）。
真正了解大规模并发系统的唯一方法就是编写一个并在实际操作中对其进行测量，这个系统本质上将展示 emergent 行为。您可以在纯Erlang中编写完全相同的程序，然后再使用gen_ *抽象作为OTP应用程序编写，并以这种方式测量性能差异 - 但基准数字只对该特定程序有任何意味着并且可能只表示该特定负载配置文件下的任何 。
考虑到这一切......当我们开始在Erlang世界中分裂头发时真正重要的数字是调度程序takes into account的减少预算成本。 Erlang Solutions的Lukas Larsson不久前发布了一个关于调度程序的视频，详细说明了这些成本对系统的影响，它们是什么，以及如何在某些情况下调整值（Understanding the Erlang Scheduler）。除了与Erlang / OTP无关的外部资源（iops延迟，网络问题，NIF疯狂等）外，压倒性因素是the behavior of the scheduler，而不是“函数调用的成本”。
但是，在所有情况下，真正了解的唯一方法是编写一个原型，代表您在实际系统中所期望的基本行为并进行测试。