为什么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

构建列表需要大约10倍的时间才能将其排除在外Task.(请注意,列表是在任务启动之前构建的.所有任务都要返回已经构建的列表.)

在列表中有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

根据@rvirding的回答,你的基本假设是有缺陷的.引用维尔丁先生:

...当前版本的Erlang基本上复制除了较大的二进制文件之外的所 在较早的SMP之前,不可复制但传递引用是可行的.虽然这导致了非常快速的消息传递,但它在实现中产生了其他问题,主要是它使垃圾收集更加困难和复杂的实现.我认为今天传递引用和共享数据可能导致过度锁定和同步,这当然不是一件好事.

在Elixir的上下文中,"较大的二进制文件"意味着非常长的字符串 - 大于64K.