为什么第一个 运行 总是慢得多？
Why is the first run always much slower?
我编写了一个宏来报告 运行 给定操作所需的时间。它 运行 多次并打印出每次 运行 的时间（以纳秒为单位）。第一个 运行 总是比后续的花费更多的时间。为什么会这样？
这是 10 x 10 运行 秒的结果，计时 Thread.yield():
> (dotimes [x 10] (prn (times 10 (Thread/yield))))
[55395 1659 622 561 591 702 795 719 742 624]
[3255 772 884 677 787 634 605 664 629 657]
[3431 789 965 671 774 767 627 627 521 717]
[2653 780 619 632 616 614 606 602 629 667]
[2373 759 700 676 557 639 659 654 659 676]
[2884 929 627 604 689 614 614 666 588 596]
[2796 749 672 769 667 852 629 589 627 802]
[1308 514 395 321 352 345 411 339 436 315]
[1390 363 328 337 330 321 324 347 333 342]
[1461 416 410 320 414 381 380 388 388 396]
第一批的第一个 运行 非常慢，我猜这是由于 JIT 第一次看到代码 - 很公平。但是所有后续批次中的前 运行s 也明显慢于随后的 运行s。为什么？
times 宏的代码：
(defmacro time
[expr]
`(let [t1# (System/nanoTime)]
~expr
(- (System/nanoTime) t1#)))
(defmacro times
[reps expr]
`(loop [reps# ~reps times# []]
(if (zero? reps#)
times#
(recur (dec reps#) (conj times# (time ~expr))))))
Decompiling 产生以下结果，因此 System.nanoTime() 似乎在 Thread.yield() 之前和之后直接被调用，如预期的那样：
> (decompile (dotimes [x 10] (prn (times 10 (Thread/yield)))))
...
public Object invoke() {
long reps__1952__auto__2355 = 10L;
Object times__1953__auto__2356 = PersistentVector.EMPTY;
while (reps__1952__auto__2355 != 0L) {
final long dec = Numbers.dec(reps__1952__auto__2355);
final IFn fn = (IFn)const__3.getRawRoot();
final Object o = times__1953__auto__2356;
times__1953__auto__2356 = null;
final long t1__1946__auto__2354 = System.nanoTime();
Thread.yield();
times__1953__auto__2356 = fn.invoke(o, Numbers.num(Numbers.minus(System.nanoTime(), t1__1946__auto__2354)));
reps__1952__auto__2355 = dec;
}
final Object o2 = times__1953__auto__2356;
times__1953__auto__2356 = null;
return o2;
}
The first run always takes significantly more time than subsequent ones. Why is that so?
基准测试结果中还有另一个棘手的依赖因素：I/O。尝试一些 return 时间向量而不是 print 的测试运行，你应该看到更符合这个的结果：
(for [_ (range 10)]
(times 10 (Thread/yield)))
=>
([32674 1539 1068 1063 1027 1026 1025 1031 1034 1035]
[1335 1048 1030 1036 1043 1037 1036 1031 1034 1047]
[1088 1043 1029 1035 1045 1035 1036 1035 1045 1047]
[1051 1037 1032 1031 1048 1045 1039 1045 1042 1037]
[1054 1048 1032 1036 1046 1029 1038 1038 1039 1051]
[1050 1051 1039 1037 1038 1035 1030 1030 1045 1031]
[1054 1045 1034 1034 1045 1037 1037 1035 1046 1044]
[1051 1041 1032 1050 1061 1039 1045 1041 1057 1034]
[1052 1042 1034 1032 1035 1045 1043 1038 1052 1052]
[1053 1053 1041 1043 1053 1044 1039 1042 1051 1038])
如果您在基准测试中使用 System.out.println 而不是 prn，您应该会看到相同的减速行为，但没有那么夸张：
(dotimes [x 10]
(.println System/out (times 10 (Thread/yield))))
=> nil
[33521 1733 1232 1161 1150 1135 1151 1138 1143 1144]
[1724 1205 1149 1152 1141 1149 1149 1150 1139 1145]
[1368 1156 1141 1139 1147 1149 1141 1147 1141 1149]
[1306 1159 1150 1141 1150 1148 1147 1142 1144 1149]
[1329 1161 1155 1144 1140 1155 1151 1149 1149 1140]
[1319 1154 1140 1143 1147 1154 1156 1149 1148 1145]
[1291 1166 1164 1149 1140 1150 1140 1152 1141 1139]
[4482 1194 1148 1150 1137 1165 1163 1154 1149 1152]
[1333 1184 1162 1163 1138 1149 1150 1151 1137 1145]
[1318 1150 1144 1150 1151 1147 1138 1147 1143 1149]
即使使用比 (Thread/yield) 更便宜且受 IO 限制更少的操作，您也可以看到这种效果，例如常量表达式 5:
user=> (doall (for [_ (range 10)] (times 10 5)))
[[390 132 134 132 109 86 94 109 115 112]
[115 117 114 112 112 89 112 112 115 89]
[117 106 109 109 109 86 109 109 111 109]
[121 106 103 103 109 86 106 106 129 109]
[117 109 106 109 112 95 111 112 109 89]
[112 112 111 111 114 92 109 112 109 114]
[118 111 112 111 115 88 112 109 115 92]
[112 108 108 111 109 92 109 109 118 89]
[115 106 112 115 112 89 112 109 114 89]
[117 109 112 112 114 89 114 112 111 91]]
很有趣，不是吗？第一个表达式总是最慢的，或者至少非常接近最慢的，奇怪的是第六个和第十个往往是最快的。为什么会这样？
我最好的猜测是 HotSpot 的神秘力量。即使在这个非常短的片段中，也有许多动态调度方法被调用。您将 conj 作为 IFn 调用，也许 HotSpot 建立了一些信心，认为您的大部分 IFn 调用将是 conj，因此它试图使该用例更快；但是在 10 的每次迭代结束时，都会调用一些其他函数，以附加到更大的结果列表，因此 HotSpot 放弃了它的优化，因为它预计你会开始做其他事情。
或者可能根本不是 HotSpot，而是与 CPU 缓存或操作系统的虚拟内存管理器或...
的某种交互
当然这个具体的场景都是推测，但关键是，即使你写的代码很简单，你也依赖大量非常复杂的系统来运行给你，最后如果不对所涉及的每个系统进行大量研究，结果基本上是不可知的。
我编写了一个宏来报告 运行 给定操作所需的时间。它 运行 多次并打印出每次 运行 的时间（以纳秒为单位）。第一个 运行 总是比后续的花费更多的时间。为什么会这样？
这是 10 x 10 运行 秒的结果，计时 Thread.yield():
> (dotimes [x 10] (prn (times 10 (Thread/yield))))
[55395 1659 622 561 591 702 795 719 742 624]
[3255 772 884 677 787 634 605 664 629 657]
[3431 789 965 671 774 767 627 627 521 717]
[2653 780 619 632 616 614 606 602 629 667]
[2373 759 700 676 557 639 659 654 659 676]
[2884 929 627 604 689 614 614 666 588 596]
[2796 749 672 769 667 852 629 589 627 802]
[1308 514 395 321 352 345 411 339 436 315]
[1390 363 328 337 330 321 324 347 333 342]
[1461 416 410 320 414 381 380 388 388 396]
第一批的第一个 运行 非常慢，我猜这是由于 JIT 第一次看到代码 - 很公平。但是所有后续批次中的前 运行s 也明显慢于随后的 运行s。为什么？
times 宏的代码：
(defmacro time
[expr]
`(let [t1# (System/nanoTime)]
~expr
(- (System/nanoTime) t1#)))
(defmacro times
[reps expr]
`(loop [reps# ~reps times# []]
(if (zero? reps#)
times#
(recur (dec reps#) (conj times# (time ~expr))))))
Decompiling 产生以下结果，因此 System.nanoTime() 似乎在 Thread.yield() 之前和之后直接被调用，如预期的那样：
> (decompile (dotimes [x 10] (prn (times 10 (Thread/yield)))))
...
public Object invoke() {
long reps__1952__auto__2355 = 10L;
Object times__1953__auto__2356 = PersistentVector.EMPTY;
while (reps__1952__auto__2355 != 0L) {
final long dec = Numbers.dec(reps__1952__auto__2355);
final IFn fn = (IFn)const__3.getRawRoot();
final Object o = times__1953__auto__2356;
times__1953__auto__2356 = null;
final long t1__1946__auto__2354 = System.nanoTime();
Thread.yield();
times__1953__auto__2356 = fn.invoke(o, Numbers.num(Numbers.minus(System.nanoTime(), t1__1946__auto__2354)));
reps__1952__auto__2355 = dec;
}
final Object o2 = times__1953__auto__2356;
times__1953__auto__2356 = null;
return o2;
}
The first run always takes significantly more time than subsequent ones. Why is that so?
基准测试结果中还有另一个棘手的依赖因素：I/O。尝试一些 return 时间向量而不是 print 的测试运行，你应该看到更符合这个的结果：
(for [_ (range 10)]
(times 10 (Thread/yield)))
=>
([32674 1539 1068 1063 1027 1026 1025 1031 1034 1035]
[1335 1048 1030 1036 1043 1037 1036 1031 1034 1047]
[1088 1043 1029 1035 1045 1035 1036 1035 1045 1047]
[1051 1037 1032 1031 1048 1045 1039 1045 1042 1037]
[1054 1048 1032 1036 1046 1029 1038 1038 1039 1051]
[1050 1051 1039 1037 1038 1035 1030 1030 1045 1031]
[1054 1045 1034 1034 1045 1037 1037 1035 1046 1044]
[1051 1041 1032 1050 1061 1039 1045 1041 1057 1034]
[1052 1042 1034 1032 1035 1045 1043 1038 1052 1052]
[1053 1053 1041 1043 1053 1044 1039 1042 1051 1038])
如果您在基准测试中使用 System.out.println 而不是 prn，您应该会看到相同的减速行为，但没有那么夸张：
(dotimes [x 10]
(.println System/out (times 10 (Thread/yield))))
=> nil
[33521 1733 1232 1161 1150 1135 1151 1138 1143 1144]
[1724 1205 1149 1152 1141 1149 1149 1150 1139 1145]
[1368 1156 1141 1139 1147 1149 1141 1147 1141 1149]
[1306 1159 1150 1141 1150 1148 1147 1142 1144 1149]
[1329 1161 1155 1144 1140 1155 1151 1149 1149 1140]
[1319 1154 1140 1143 1147 1154 1156 1149 1148 1145]
[1291 1166 1164 1149 1140 1150 1140 1152 1141 1139]
[4482 1194 1148 1150 1137 1165 1163 1154 1149 1152]
[1333 1184 1162 1163 1138 1149 1150 1151 1137 1145]
[1318 1150 1144 1150 1151 1147 1138 1147 1143 1149]
即使使用比 (Thread/yield) 更便宜且受 IO 限制更少的操作，您也可以看到这种效果，例如常量表达式 5:
user=> (doall (for [_ (range 10)] (times 10 5)))
[[390 132 134 132 109 86 94 109 115 112]
[115 117 114 112 112 89 112 112 115 89]
[117 106 109 109 109 86 109 109 111 109]
[121 106 103 103 109 86 106 106 129 109]
[117 109 106 109 112 95 111 112 109 89]
[112 112 111 111 114 92 109 112 109 114]
[118 111 112 111 115 88 112 109 115 92]
[112 108 108 111 109 92 109 109 118 89]
[115 106 112 115 112 89 112 109 114 89]
[117 109 112 112 114 89 114 112 111 91]]
很有趣，不是吗？第一个表达式总是最慢的，或者至少非常接近最慢的，奇怪的是第六个和第十个往往是最快的。为什么会这样？
我最好的猜测是 HotSpot 的神秘力量。即使在这个非常短的片段中，也有许多动态调度方法被调用。您将 conj 作为 IFn 调用，也许 HotSpot 建立了一些信心，认为您的大部分 IFn 调用将是 conj，因此它试图使该用例更快；但是在 10 的每次迭代结束时，都会调用一些其他函数，以附加到更大的结果列表，因此 HotSpot 放弃了它的优化，因为它预计你会开始做其他事情。
或者可能根本不是 HotSpot，而是与 CPU 缓存或操作系统的虚拟内存管理器或...
的某种交互当然这个具体的场景都是推测，但关键是，即使你写的代码很简单，你也依赖大量非常复杂的系统来运行给你，最后如果不对所涉及的每个系统进行大量研究，结果基本上是不可知的。