可以通过以下方式有效地构建二进制：

my_list_to_binary(List) ->

    my_list_to_binary(List, <<>>).

​

my_list_to_binary([H|T], Acc) ->

    my_list_to_binary(T, <<Acc/binary,H>>);

my_list_to_binary([], Acc) ->

    Acc.

二进制可以像这样有效地匹配：

my_binary_to_list(<<H,T/binary>>) ->

    [H|my_binary_to_list(T)];

my_binary_to_list(<<>>) -> [].

4.1如何实现二进制

在内部，二进制和位串以相同的方式实现。在本节中，它们被称为二进制，因为这就是它们在模拟器源代码中的名称。

内部有四种类型的二进制对象：

  • 两个是二进制数据的容器，它们被称为：

    • Refc Binaries（引用计数二进制的缩写）
    • 堆二进制
  • 两个仅仅是对二进制一部分的引用，它们被称为：

    • 子二进制
    • 匹配上下文

Refc二进制

Refc二进制包含两个部分：

  • 存储在进程堆上的对象，称为ProcBin
  • 二进制对象本身，存储在所有进程堆的外部

二进制对象可由任意数量的进程中的任意数量的ProcBins引用。该对象包含一个引用计数器，以跟踪引用的数量，以便在最后一个引用消失时可以将其删除。

进程中的所有ProcBin对象都是链接列表的一部分，因此，当ProcBin消失时，垃圾收集器可以跟踪它们并减少二进制中的引用计数器。

堆二进制

堆二进制是小型二进制，最多64个字节，并直接存储在进程堆中。当进程被垃圾回收并且作为消息发送时，它们被复制。它们不需要垃圾收集器进行任何特殊处理。

子二进制

引用对象子二进制和匹配上下文可以引用refc二进制或堆二进制的一部分。

子二进制通过创建split_binary/2，并且当二进制以二进制模式匹配的。子二进制是对另一个二进制（refc或堆二进制，而不是对另一个子二进制）的一部分的引用。因此，匹配二进制相对便宜，因为从不复制实际的二进制数据。

匹配上下文

匹配上下文类似于子二进制，但对于二进制匹配被优化。例如，它包含一个指向二进制数据的直接指针。对于从二进制中匹配的每个字段，匹配上下文中的位置会增加。

编译器试图避免生成用于创建子二进制的代码，而只是在不久之后创建一个新的匹配上下文并丢弃该子二进制。保留匹配上下文，而不是创建子二进制。

如果编译器知道不会共享匹配上下文，则只能进行此优化。如果将其共享，则Erlang的功能属性（也称为参照透明性）将中断。

4.2构造二进制

运行时系统特别优化了附加到二进制或位串的操作：

<<Binary/binary, …>>

<<Binary/bitstring, …>>

当运行时系统处理优化（而不是编译器）时，在极少数情况下优化不起作用。

为了解释它是如何工作的，让我们逐行检查以下代码：

Bin0 = <<0>>,                    %% 1

Bin1 = <<Bin0/binary,1,2,3>>,    %% 2

Bin2 = <<Bin1/binary,4,5,6>>,    %% 3

Bin3 = <<Bin2/binary,7,8,9>>,    %% 4

Bin4 = <<Bin1/binary,17>>,       %% 5 !!!

{Bin4,Bin3}                      %% 6

  • 第1行（标有%% 1注释）将堆二进制分配给Bin0变量。
  • 第2行是追加操作。由于Bin0尚未参与追加操作，新的REFC二进制被创建和内容Bin0被复制到它。refc二进制的ProcBin部分的大小设置为存储在二进制中的数据的大小，而二进制对象分配了额外的空间。二进制对象的大小是Bin1或256的大小的两倍，以较大者为准。在这种情况下为256。
  • 第3行更有趣。Bin1已经在附加操作中使用，并且它具有252个字节在末端未使用的存储空间，所以3个新字节被存储在那里。
  • 第4行。此处同样适用。剩下249个字节，因此存储另外3个字节没有问题。
  • 第5行。在这里，发生了一些有趣的事情。请注意，结果不追加到以前的结果Bin3，但Bin1。预期将为Bin4赋值<<0,1,2,3,17>>。还可以预期Bin3将保留其值（<<0,1,2,3,4,5,6,7,8,9>>）。显然，运行时系统无法将字节17写入二进制，因为这会将Bin3的值更改为<<0,1,2,3,4,17,6,7,8,9>>。

运行时系统会发现Bin1是上一个追加操作（不是最新的追加操作）的结果，因此它将Bin1的内容复制到新的二进制中，保留了额外的存储空间，依此类推。（这里没有解释运行时系统如何知道不允许将其写入Bin1；好奇的读者可以将其作为练习，通过读取仿真器源代码（主要是erl_bits.c）来了解如何完成此操作。）

强制复制的情况

二进制追加操作的优化要求，有一个单一ProcBin和一个单一的引用到ProcBin用于二进制。原因是可以在追加操作期间移动（重新分配）二进制对象，并且在这种情况下，必须更新ProcBin中的指针。如果将有多个ProcBin指向二进制对象，则将不可能找到并更新所有它们。

因此，对二进制的某些操作会对其进行标记，以便将来任何附加操作都将被强制复制二进制。在大多数情况下，二进制对象将同时缩小以回收分配给增长的额外空间。

当按如下所示追加到二进制时，仅从最新的追加操作返回的二进制将支持进一步的廉价追加操作：

Bin = <<Bin0,…>>

在本节开头的代码片段中，追加到Bin将很便宜，而追加到Bin0将强制创建新的二进制并复制Bin0的内容。

如果将二进制作为消息发送到进程或端口，则该二进制将缩小，并且任何进一步的追加操作会将二进制数据复制到新的二进制中。例如，在下面的代码片段中，Bin1将被复制到第三行：

Bin1 = <<Bin0，…>>，

PortOrPid！Bin1

Bin = <<Bin1，…>>   %% Bin1将被复制

如果将二进制插入到Ets表中，或者使用erlang:port_command/2将其发送到端口，或者将其传递给NIF中的enif_inspect_binary，也会发生同样的情况。

匹配二进制也将导致其缩小，并且下一个追加操作将复制二进制数据：

Bin1 = <<Bin0，…>>，

<< X，Y，Z，T/binary>> = Bin1，

Bin = <<Bin1，…>>   %% Bin1将被复制

原因是匹配上下文包含指向二进制数据的直接指针。

如果进程仅保留二进制（在“循环数据”中或在进程字典中），则垃圾收集器最终可以收缩二进制。如果只保留一个这样的二进制，它将不会缩小。如果该过程稍后追加到已缩小的二进制中，则将重新分配二进制对象以放置要附加的数据。

4.3匹配二进制

让我们回顾上一节开头的示例：

my_binary_to_list （<< H，T/binary >>） ->

    [H | my_binary_to_list（T）];

my_binary_to_list （<< >>） -> []。

首次调用my_binary_to_list/1时，将创建一个匹配上下文。匹配上下文指向二进制的第一个字节。1个字节被匹配，并且匹配上下文被更新以指向二进制中的第二个字节。

在这一点上，创建一个子二进制是有意义的，但是在此特定示例中，编译器发现很快将调用一个函数（在本例中为my_binary_to_list/1本身），该函数将立即创建一个新的匹配上下文并丢弃子二进制。

因此，my_binary_to_list/1会使用match上下文而不是子二进制进行调用。初始化匹配操作的指令在看到已传递给匹配上下文而不是二进制时，基本上什么也不做。

当到达二进制的末尾并且第二个子句匹配时，匹配上下文将被简单地丢弃（在下一个垃圾回收中将其删除，因为不再有对其的引用）。

总而言之，my_binary_to_list/1仅需要创建一个匹配上下文，而无需子二进制。

请注意，遍历整个二进制后，将放弃my_binary_to_list/1中的match上下文。如果迭代在到达二进制末尾之前停止，会发生什么情况？优化是否仍然有效？

after_zero(<<0,T/binary>>) ->

    T;

after_zero(<<_,T/binary>>) ->

    after_zero(T);

after_zero(<<>>) ->

    <<>>.

是的，它会的。编译器将在第二个子句中删除子二进制的构建：

…

after_zero(<<_,T/binary>>) ->

    after_zero(T);

…

但是它将生成在第一个子句中构建子二进制的代码：

after_zero(<<0,T/binary>>) ->

    T;

…

因此，after_zero/1构建一个匹配上下文和一个子二进制（假定传递了一个包含零字节的二进制）。

如下代码也将得到优化：

all_but_zeroes_to_list(Buffer, Acc, 0) ->

    {lists:reverse(Acc),Buffer};

all_but_zeroes_to_list(<<0,T/binary>>, Acc, Remaining) ->

    all_but_zeroes_to_list(T, Acc, Remaining-1);

all_but_zeroes_to_list(<<Byte,T/binary>>, Acc, Remaining) ->

    all_but_zeroes_to_list(T, [Byte|Acc], Remaining-1).

编译器在第二和第三子句中删除了子二进制的构建，并向第一子句添加了一条指令，该指令将Buffer从匹配上下文转换为子二进制（如果Buffer已经是二进制，则不执行任何操作）。

但是在更复杂的代码中，如何知道是否应用了优化呢？

选项bin_opt_info

使用bin_opt_info选项可使编译器打印许多有关二进制优化的信息。可以将其提供给编译器或erlc：

erlc +bin_opt_info Mod.erl

或通过环境变量传递：

export ERL_COMPILER_OPTIONS=bin_opt_info

注意，bin_opt_info并不是要添加到Makefile的永久选项，因为它生成的所有消息都无法消除。因此，在大多数情况下，将选项传递给环境是最实用的方法。

警告如下：

./efficiency_guide.erl:60：警告：未优化：该函数返回了二进制

./efficiency_guide.erl:62：警告：已优化：匹配上下文已重用

为了更清楚地说明警告所指的代码，例如，以下示例中的警告以注释的形式插入它们所引用的子句之后，例如：

after_zero （<< 0，T/binary>>） -> %% BINARY CREATED：从函数返回二进制

    T;

after_zero （<< _，T/binary >>） -> %%优化：重用匹配上下文

    after_zero（T）;

after_zero （<< >>） ->

    << >>。

第一个子句的警告说，不能延迟子二进制的创建，因为它将被返回。第二个子句的警告说将不会创建子二进制。

未使用的变量

编译器会确定变量是否未使用。为以下每个功能生成相同的代码：

count1(<<_,T/binary>>, Count) -> count1(T, Count+1);

count1(<<>>, Count) -> Count.

​

count2(<<H,T/binary>>, Count) -> count2(T, Count+1);

count2(<<>>, Count) -> Count.

​

count3(<<_H,T/binary>>, Count) -> count3(T, Count+1);

count3(<<>>, Count) -> Count.

在每次迭代中，二进制中的前8位将被跳过，不匹配。

4.4历史记录

R12B中的二进制处理得到了显着改善。由于在R11B中有效的代码在R12B中可能无效，反之亦然，因此本《效率指南》的较早版本包含一些有关R11B中二进制处理的信息。

版权声明：本文为sunbin-hello原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://www.cnblogs.com/sunbin-hello/p/13099209.html