Привет! В первой и второй частях я поделился историей создания python библиотеки convtools (кратко: позволяет декларативно описывать преобразования данных, из которых генерируются python функции, реализующие заданные преобразования), сейчас расскажу об ускорении частных случаев datetime.strptime и datetime.strftime, а также о том интересном, что встретилось в datetime модуле по дороге. Для начала сделаем замеры базового варианта форматирования даты/даты и времени: Взглянув на код выше, а также осмотрев исходники strftime, можно найти следующие проблемы: на каждом запуске функции strftime интерпретатор делает разбор строки формата даты с нуля (не используя каких-либо промежуточных наработок с предыдущих итераций). дата предварительно превращается в timetuple, с которым уже может работать time.strftime. Но т.к. timetuple содержит все компоненты даты и времени, то для его создания интерпретатор проделал лишнюю работу, общупав часы, минуты, секунды и микросекунды, которые в данном конкретном случае нас совершенно не интересовали. Теперь давайте проверим насколько быстро могла бы работать самая узколобая функция, которая реализует почти такое же форматирование дат (почти, т.к. тут игнорируется разное название месяцев в зависимости от локали): Получили ускорение в ~ 4.7 раза и постановку задачи для convtools - уметь  динамически генерировать узкоспециализированные конвертеры под заданный формат даты. До того, как мы осмотрим результат, сделаю некоторые замечания: dt.strftime("%Y-%m-%d") использовать неоптимально. Лучше использовать dt.date().isoformat() для datetime и dt.isoformat() для date (ускорение 5.5x и 6.4x соответственно) — учтено в реализации. dt.strftime("%Y"): по форматированию года документация не делает каких-либо оговорок (как минимум для python 3.4+), а вот CPython bugtracker делает (#57514) - под linux glibc python не делается zero padding (на маке и linux musl делается). Можно вылечить вот так dt.strftime("%4Y"), но сломаем для остальных — учтено в реализации. многие коды формата, такие как %a, %b, %c, %p зависят от локали, установленной в системе (например: Sunday, Monday, …, Saturday для en_US и Sonntag, Montag, …, Samstag для de_DE) -- реализована только часть таких кодов, при встрече неподдерживаемого, используется встроенная strftime. По дороге немного потеряли, но все же имеем ускорение в 4.4 раза от базового варианта. Чтобы посмотреть, какой код был сгенерирован под капотом, просто запускаем с debug=True(try-except обвязка сбрасывает сгенерированный код в tmp в случае ошибки ради красивых traceback-ов и нормальной отладки): Повторим шаги выше для datetime.strptime, но немного срезая углы. Забегая вперед, отмечу, что оптимизировать работу с кодами формата, которые зависят от локали, мы не будем. Осмотрев исходники, находим кэш для скомпилированных регулярных выражений, локи для доступа к нему, в целом все хорошо, но все же сравним с узкоспециализированным кодом. Имеем прирост по скорости в 3.6 раза - ощутимо. Посмотрим на код, сгенерированный под капотом: За все приходится чем-то платить, в случае с convtools это время на кодогенерацию и компиляцию конвертеров: Поэтому до того, как использовать сей функционал, нужно осмыслить, подпадает ли Ваш случай, под один из нижеперечисленных: формат даты статичен (известен на момент написания кода) и Вы можете единожды вызвать gen_converter где-то глобально и далее его использовать формат даты динамический, но сгенерированный конвертер будет использован для обработки, скажем, хотя бы 1K (тысячи) дат. Вышеописанный функционал далеко не единственное, что предлагает библиотека convtools, более подробно Вы можете ознакомиться с ней по ссылкам ниже: https://convtools.readthedocs.io/en/latest/ https://github.com/westandskif/convtools Буду благодарен за отзывы, идеи в дискуссиях на Github.  Software engineer