Почему первый запуск всегда намного медленнее?

Первый запуск всегда занимает значительно больше времени, чем последующие. Почему это так?

Есть еще одна сложная зависимость, учитывающая ваши результаты тестов: ввод-вывод. Попробуйте выполнить несколько тестовых прогонов, которые возвращают векторы времени, а не выводят их, и вы должны увидеть результаты, более соответствующие этому:

(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), такой как константное выражение 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, а какое-то взаимодействие с кешем процессора, или диспетчером виртуальной памяти операционной системы, или...

Конечно, этот конкретный сценарий — все предположения, но дело в том, что даже когда вы пишете очень простой код, вы полагаетесь на большое количество очень сложных систем, чтобы запустить его для вас, и конечный результат в основном неизвестен, не посвятив много времени. изучения каждой из задействованных систем.