Как стать автором
Обновить

Комментарии 11

НЛО прилетело и опубликовало эту надпись здесь
Какая-то работа с датами, например, есть почти на всех страницах сайта. А где-то её даже много (навскидку — форматирование/локализация дат в каком-нибудь большом списке, например, счетов пользователя или операций). Заменить инструмент и получить прирост по скорости даже пусть, условно, 1%, но в очень большом количестве мест — вроде и пустячок, но приятно.

А какие есть причины не использовать более быстрый модуль вместо/параллельно DateTime там, где его можно использовать, и он приносит профит? У нас с DateTime свободные отношения и никаких обязательств хранить друг другу верность.
НЛО прилетело и опубликовало эту надпись здесь

В моей задаче надо сделать вычисления с датами раз в секунду за интервал в два дня. Вариант с Time::Moment делает это в 70 раз быстрее чем вариант с DateTime. Такая разница заставляет задуматься.
Причём некоторые операции (парсинг) я делаю с DateTime.

Статистика и отчеты, какие-нибудь сервисы работающие под большой нагрузкой (вроде очередей). Да много где еще может возникнуть вопрос о быстродействии (и потреблении памяти кстати тоже). Если проблем со скоростью DateTime нет — то конечно нет смысла переписывать код. Но если проблемы все таки возникли — есть хорошие альтернативы.

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

В конечном счета, каждая команда сама решает нужны ли альтернативы и дополнительные зависимости в проекте.
Спасибо за обзор.

Конечно, надо использовать лучшие решения, и быстродействие — решающий фактор в конечно итоге.

Time::Moment использует XS — поэтому работает быстро.
Спасибо за тест. Пригодился.

Но написание в Readme хотя бы:
cpanm Modern::Perl DateTime Date::Manip Time::Piece Panda::Date Date::Calc Time::Moment DateTime::Format::ISO8601
или приложенный cpanfile сильно сэкономили бы время, и позволило бы прогнать тесты неопытным пользователям(или тем кому лень выяснять, почему они не хотят запускаться просто так)

P.S.: Кстати, модель процессора стоит указывать точнее. Я проверил тесты на Xeon E3-1240 V2 и i7-3770 — и результат сильно в некоторых случаях отличается в пользу Panda::Time
Спасибо за замечания. Внес дополнительную информацию в статью и readme к тестам.

А какие результаты получились у Вас?
О, спасибо. Я использовал DateTime из-за клевой поддержки таймзон. Но да, он монструозный.
Не затронут один важный показатель — интервал дат, с которым работают модули. Большинство из них построено на целом числе — то есть секунды с 1970-го года по 2037-й (если не ошибаюсь), так что даже дату ВОВ они представить не могут. DateTime тут чуть лучше, но и тут, как видно, всё зависит от разрядности:

Internally, dates are represented the number of days before or after 0001-01-01. This is stored as an integer, meaning that the upper and lower bounds are based on your Perl's integer size ($Config{ivsize}).

The limit on 32-bit systems is around 2^29 days, which gets you to year (±)1,469,903. On a 64-bit system you get 2^62 days, (±)12,626,367,463,883,278 (12.626 quadrillion).

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