Цели разработки java.time включали ясное и ожидаемое поведение, неизменные объекты, безопасность потоков, использование стандартов и ряд других моментов. Цели не включали в себя выполнение быстрее, чем старые классы даты и времени, включая Calendar
. Кроме того, хотя я слышал слышал многочисленные жалобы на старые классы, я слышал нет жалоб на то, что они выполнялись слишком плохо.
Если намного превосходящий дизайн современного API в некоторых случаях стоит потери производительности, я не думаю, что мы должны удивляться или беспокоиться.
Ваши измерения не заслуживают доверия, хотя. Правильный бенчмаркинг сложнее, чем это. Я также провел несколько ненадежных измерений: на моем компьютере я только что получил 124 178 930 нанограмм для Calendar
и 66 794 865 для ZonedDateTime
, примерно половину, используя System.nanoTime()
для измерений. YearMonth.now().getMonthValue()
(также из java.time), выполненный всего за 8 339 306, около 15-го (1/15) Календаря.
Тот факт, что для Calendar
нужно добавить 1 к значению месяца, а читателю необходимо понять, почему вы добавляете 1, гораздо важнее производительности, для 99,5% случаев.
Конечно, если в вашей конкретной системе у вас есть узкое место в производительности и надежные измерения говорят вам, что переключение одного из ваших методов на использование Calendar
, Time4J , Joda-Time, некоторая библиотека Apache или некоторый C-код решит эту проблему, это вполне веская причина для этого. Мне трудно представить, что это будет так, но опять же, я не знаю всех компьютерных систем в мире.
Ссылки