Продолжаем серию охуительных историй про производительность простейших операций Итак, есть бенчмарк, который просто обходит большой массив и суммирует элементы http://ideone.com/UtpVej Запускаем под последней оракловой jvm: $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 0 -10621346557024: 43 $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 1 -10621346557024: 42 $ /opt/oracle-jdk-bin-1.8.0.20/bin/java Iter 100000000 2 -10621346557024: 48 Казалось бы логично — обход массиве в обратном направлении не cache-friendy Запускаем под айбиэмовской машиной: $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 0 -10621346557024: 107 $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 1 -10621346557024: 98 $ /opt/ibm/java-x86_64-71/bin/java Iter 100000000 2 -10621346557024: 90 Если отбросить тот факт, что работает медленно, можно отметить, что реализация обратного обхода и должна была работать быстрее, потому что в байткоде видно, что размер массива загружается всего один раз, а в реализации с прямым циклом по массиву его приходится получать каждый раз. В общем, я продолжаю охуевать от айбиэмовских jvm и продолжаю их использовать в силу более быстрого gc

специально для @lord: http://ideone.com/qG6C2N tl;dr: стандартная работа со временем в go такая же медленная как в джаве, а joda-time — рулит