不过，变量复制的代价是可以接受的，多谢你的回复。

你们翻译的《Programming Erlang》出版得太晚了，英文电子版我已经看了好几遍，不然一定买。

还有就是感觉那本书太基础了些，erlang领域有没有深一些的书籍呢。

对于这个结果，我的看法不同。我们写程序时，性能不应该被预先排在第一位，就算单单只考虑性能，问题也往往会很复杂。

record 的 copy 毕竟也是 copy，肯定会有消耗。它比增加变量要复杂，才慢上 3 倍，已属不错(我估计，如果 record 更复杂，会慢得更多)。不过执行 1 次消耗 0.172 毫秒，在性能上，完全处在可以接受的范围。况且，这样的语法，还有易于理解，便于维护的好处(比如，要加一个字段)。

如果对采用 record 的程序改用 “增加变量” 的方式来改写，且不谈对程序的可读性会带来多大影响，单从性能而言，我认为对整体性能提升的贡献也可能极为有限(比如，毫秒级)，而通过 profiler 你可能会发现严重得多的性能瓶颈(比如，逻辑上的问题，IO，流程等等)，修正这些问题往往会带来大得多的性能提升(比如，解决了一个瓶颈，一下子快上个几十上百倍完全是有可能的)。

-record(obj,{x1,x2,x3,x4,x5}).

start()->
N = 1000000,
Obj = #obj{x1=N,x2=0,x3=0,x4=0,x5=0},
T0 = now(),
loop1(N,Obj),
T1 = now(),
loop2(N,0,0,0,0,0),
T2 = now(),
loop3(N,0),
T3 = now(),
io:format(“T:~p,~p,~p~n”,[timer:now_diff(T1,T0),timer:now_diff(T2,T1),timer:now_diff(T3,T2)]).

loop1(0,_)->
ok;
loop1(N,Obj)->
loop1(N-1,Obj#obj{x1=N}).

loop2(0,_,_,_,_,_)->
ok;
loop2(N,X1,X2,X3,X4,X5)->
loop2(N-1,N,X2,X3,X4,X5).

loop3(0,_)->
ok;
loop3(N,X1)->
loop3(N-1,N).

结果如下：
T:172000,47000,46000

可以看出复制数据的开销确实不小，增加函数参数也会带来一定开销，但相对小很多。

A。为时间和空间上的性能考虑，允许修改内存，但会引入 “顺序瓶颈” 。
B。不允许修改内存，用更 “浪费” 的方式，但不会引入 “顺序瓶颈” 。

你已经知道 Erlang 在这里的设计决策是方案 B。

另外，语义和语句是两回事，虽然没有看到确切的代码，但在实现上 BEAM 的底层并不一定会排斥 “修改内存” 的实现手段。比如，若能通过语义分析排除 “共享” 的情况，完全可以很安全的使用 “修改内存” 的方式来实现上述语义。

使用“高级语言”时，如果总是忍不住在揣度它的底层实现，并因此而担心“时间和空间开销”。那还不如自己动手，写段测试代码来一探究竟。若有所收获，可别忘了与社区共享哦。

我写的代码只是举例，实际使用并不是这个情形

包装成record我也考虑过，但有另外一个担忧。每次更改一个属性，都要复制整个record，在上面的例子，就是100倍的时间和空间开销。

-record(state, {a, b, c, d}).

loop(State)->
receive
{update,a}->
loop(State#state{a=State#state.a + 1});
{update,b}->
loop(State#state{b=State#state.b + 1}});
……
{update,d}->
loop(State#state{d=State#state.d + 1}})
end.

更进一步，如果你的对应关系如此明确的话，record 仍是 tuple ，你还有 nth() 函数可以用。

但是，这个问题也有其他解决方法，比如haskell就提供了一些难于看懂但确实比较美观的“省略”语法（$、.等）。