在我正在构建的测试中，我的目标是创建一个解析器。所以我构建了一个概念证明，它从文件中读取所有消息，并在将所有消息推送到内存后，我正在生成一个进程来解析每个消息。在那之前，一切都很好，我有一些不错的结果。但是我可以看到erlang VM没有使用我所有的处理器能力（我有一个四核），事实上它在我的测试中使用了大约25％的处理器。我使用c ++进行了反测试，使用了四个线程，显然它使用了100％，从而产生了更好的结果（我尊重erlang使用的相同队列模型）。
所以我想知道什么可能“减慢”我的erlang测试？我知道这不是序列化问题，因为我每个消息产生一个进程。我想到的一件事是，我的信息可能太小（每个约10k），因此制作大量的流程无助于实现卓越的性能。
关于测试的一些事实：
106k条消息 在erlang上（使用25％的处理器功率） - 204毫秒 在我的C ++测试中（使用100％处理器功率） - 80毫秒
是的，区别并不是那么好但是如果有更多的可用功率肯定还有更大的改进空间，对吗？
啊，我已经完成了一些练习并且无法找到另一种优化方法，因为几乎没有函数调用，而且大多数都是字符串到对象的转换。
更新
Woooow！遵循Hassan Syed的想法，我已经成功地从c ++达到了35毫秒，而80！这太棒了！
答案 0 :(得分：4)
您的erlang VM似乎只使用一个核心。
尝试这样开始：
erl -smp enable +S 4
-smp enable标志告诉Erlang在启用SMP支持的情况下启动运行时系统 使用+ S 4，您可以启动4个Erlang调度程序（每个核心1个）
启动shell时，您可以看到是否启用了SMP：
Erlang R13B01 (erts-5.7.2) [source] [64-bit] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]
Eshell V5.7.2 (abort with ^G)
1>
[smp：2：2]告诉它正在运行smp启用2个调度程序2个schesulers online
答案 1 :(得分：2)
如果您有一个源文件并且每个“表达式”产生一个进程，那么您真的不明白何时进行并行化。生成，处理和处理表达式的成本要高于只有一个进程来处理整个文件。一个合适的策略是每个文件有一个进程，而不是每个表达式有一个进程。
另一种替代策略是将文件拆分为两个，三个或x个块，然后处理这些块。这当然假设源不是线性相关的，并且块的处理时间需要超过创建和生成过程的时间（到目前为止，因为过程X中的时间浪费是从机器的其余部分带走的时间） 。
- 讨论C ++ vs Erlang以及你的发现 -
Erlang有一个用户空间内核，可以模拟操作系统内核的许多原语。特别是调度程序和阻塞原语。这意味着在比较过程原始语言（如C ++）中使用的相同策略时会有一些开销。您必须根据其属性将任务分区调整为实现空间（CPU /内存/ OS /编程语言）中的每个条目。
答案 2 :(得分：2)
您应该将调度程序绑定到CPU核心：
erlang:system_flag(scheduler_bind_type, processor_spread).