只是为了报告的两种方法(@@@
,@@ # & /@
)令人费解的性能测试:
T = RandomReal[{1,100}, {1000000, 2}];
H[F_Symbol, T_List] :=
[email protected][F @@@ T;]/[email protected][F @@ # & /@ T;]
Table[{ToString[F], H[F, T]}, {F, {Plus, Subtract, Times, Divide, Power, Log}}]
Out[3]= {{"Plus", 4.174757},
{"Subtract", 0.2596154},
{"Times", 3.928230},
{"Divide", 0.2674164},
{"Power", 0.3148629},
{"Log", 0.2986936}}
这些结果不是随机的,而是大致比例非常不同的数据大小。
@@@
是更快Subtract
大约3-4次,Divide
,Power
,Log
而@@ # & /@
是更快Plus
和Times
引起另一个问题,这(为一个可以相信)有可能会稍微
通过澄清4倍以下评价:
[email protected]{Plus, Subtract, Times, Divide, Power, Log}
只有Plus
和Times
有属性Flat
和Orderless
,之间的休息,而只有Power
(这似乎相对最有效)也有一个属性OneIdentity
。
编辑
一个可靠的解释观测到的性能提升(感谢列昂尼德·希夫林的言论)应沿着不同的路线走。
默认情况下有MapCompileLength -> 100
,因为我们可以检查评估SystemOptions["CompileOptions"]
。 要重置地图autocompilation我们可以评估:
SetSystemOptions["CompileOptions" -> "MapCompileLength" -> Infinity]
现在我们可以通过评估一次我们H
测试的两种方法相对性能 - 对相关符号的性能测试功能列表:
Table[{ToString[F], H[F, T]}, {F, {Plus, Subtract, Times, Divide, Power, Log}}]
Out[15]= {{"Plus", 0.2898246},
{"Subtract", 0.2979452},
{"Times", 0.2721893},
{"Divide", 0.3078512},
{"Power", 0.3321622},
{"Log", 0.3258972}}
有了这些结果,我们可以得出结论,一般来说尤达的方法(@@@
)是最有效的,而由Andrei提供的方法在Plus
和Times
的情况下更好,因为自动编译的Map
允许更好的p (@@ # & /@
)的性能。
[相关](http://stackoverflow.com/q/5746717/499167)问题:**将列表应用于Mathematica中的参数** – tomd 2012-01-07 00:43:18