performance - 为什么 Elixir 消息传递时间与消息大小成正比？

Question

我发现在 Elixir 中传递消息所需的时间与消息的大小成正比，而我希望它相对恒定。由于数据结构是不可变的，因此运行时应该能够通过引用(在恒定时间内)在进程之间传递大型结构。考虑以下测试。

use Bitwise

defmodule PerfTask do
  def pack(s) do
    {millis, packed} = :timer.tc(fn -> Enum.to_list(s) end)
    IO.puts("packed in #{millis} millis")
    Task.async(fn -> packed end)    
  end

  def unpack(t) do
    {millis, unpacked} = :timer.tc(fn -> Task.await(t) end)
    IO.puts("unpacked in #{millis} millis")
    unpacked
  end

  def go(n) do
    IO.puts "n = #{n}"
    1..n |> pack |> unpack
  end
end

PerfTask.go(1 <<< 20)

列表中有 2^20 个元素，这将打印

n = 1048576
packed in 106481 millis
unpacked in 9916 millis

构建列表所需的时间大约是从 Task 中取出列表所需时间的 10 倍。 . (请注意，列表是在任务开始之前构建的。任务所要做的就是返回已经构建的列表。)

列表中有 2^22 个元素，它会打印

n = 4194304
packed in 397428 millis
unpacked in 38748 millis

比例仍然约为 10:1。 4 倍长的列表需要 4 倍的时间在进程之间发送。我错过了什么？

$ iex
Erlang/OTP 18 [erts-7.2] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false]

Interactive Elixir (1.2.0) - press Ctrl+C to exit (type h() ENTER for help)

(我已经确认该问题不是 Task 模块特有的，而是将其替换为具有相似结果的普通进程。)

Answer 1

根据这个 answer从@rvirding 你的基本假设是有缺陷的。引用维丁先生的话:

. . . current versions of Erlang basically copy everything except for larger binaries. In older pre-SMP times it was feasible to not copy but pass references. While this resulted in very fast message passing it created other problems in the implementation, primarily it made garbage collection more difficult and complicated implementation. I think that today passing references and having shared data could result in excessive locking and synchronisation which is, of course, not a Good Thing.

在 Elixir 的上下文中，“更大的二进制文件”意味着非常长的字符串——大于 64K。