C++: вы выберете библиотеку boost::date_time или icu::date/time?

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

Если ваш вариант использования включает «общие» операции с датой/временем (то есть, вы еще не знаете весь спектр операций с датой/временем, которые вам нужны), есть несколько вариантов, которые вы должны сделать. . Как указано в документации Boost.DateTime объясняет, у вас есть выбор между этими тремя возможностями:

1. Точное соответствие времени настенных часов
2. Точные расчеты между моментами времени
3. Способность обрабатывать моменты времени в будущем

Одна из причин, по которой ни одна библиотека не может неявно обрабатывать все три одновременно, заключается в том, что определение того, существует ли летнее время в данный момент времени, зависит от юрисдикции, ее политических проблем и множества других факторов. Таким образом, расчеты, включающие будущие даты, могут стать неточными.

Выбирая между этими возможностями, вы заметите, что важную роль играют география и локализация. Если, например, ваши требования к дате/времени должны поддерживать только одну локаль, нет оправданной причины вводить большую библиотеку ICU в качестве зависимости. Но вам, вероятно, также не следует использовать Boost.DateTime: как библиотека, не зависящая от локали, она игнорирует тот факт, что первый день недели зависит от локали. Кроме того, поддержка часового пояса Boost.DateTime нарушена< /а>; большинство современных программ используют базу данных Olson для обработки и преобразования часовых поясов. Вместо этого вам, вероятно, следует рассмотреть Boost.Locale при использовании Boost для работы с датами, временем и календарями.,

По умолчанию Boost.Locale использует ICU для всех локализаций. задач, но предоставляет возможность использовать серверную часть локализации, не основанную на ICU. Итак, если вы не используете Boost в другом месте (по какой-либо причине) и вам необходимо поддерживать часовые пояса за пределами текущего часового пояса ОС и часовых поясов, смещенных от UTC (игнорируя летнее время), используйте только ICU. Если вы используете Boost в другом месте, у вас есть выбор между Boost.Locale и ICU, но различия минимальны (в конце концов, ICU включен, так что это действительно вопрос стилистики и согласованности). Окончательный выбор возникает, когда вы не используете Boost в другом месте и имеете дело только с датами в часовом поясе ОС (или изменениями даты с использованием априорно известного смещения от UTC). В этом случае вам, вероятно, следует использовать Boost.Locale.DateTime, но без поддержки ICU.

Резюме

• Не используйте Boost.DateTime по двум причинам: (1) его поддержка часового пояса нарушена; и (2) он игнорирует тот факт, что расчеты «дня недели» зависят от локали. Вместо этого используйте Boost.Locale.DateTime.
• Если вы используете Boost в другом месте, продолжайте его использовать. Он будет автоматически включать серверную часть локализации на основе ICU. Вы также можете вызвать их напрямую (прямо включив ICU), но большой разницы нет.
• Если вы не используете Boost в другом месте, ваш выбор зависит от того, не зависит ли вариант использования от региональных настроек. Если он не зависит от языкового стандарта, вы можете использовать бэкенды локализации Boost.Locale.DateTime, не основанные на ICU (например,, std, posix) и избежать накладных расходов ICU. В качестве альтернативы, если ваш вариант использования зависит от локали, вы можете использовать ICU без дополнительных затрат на Boost.
• О производительности: профилирование — единственный способ узнать.