Как я ускорил dependency injection в Python в 130 раз: от рефлексии до компиляции графа

[Tishka17]

По моему опыту, компиляция всего графа в одну функцию не очень хорошо ложится на кэширование/обработку ошибок и прочее. Функции становятся гигантскими, код грязным и прочее оно тормозит уже на этом этапе.

Я компилирую каждую обертку над конструктором, не весь граф. Это всё ещё работает очень быстро и не лишает вас других фич, которых можно напридумывать миллион.

Вижу что вы сравниваете скорость с wireup и dependency-injector, а с dishka не пробовали?

[VShulcz]

Injex компилирует не весь граф в одну функцию, а только транзиентную цепочку. Листья - синглтоны, scoped, инстансы, остаются отдельными переиспользуемыми creators: синглтон в плоской функции - один вызов геттера, посчитанный раз, а не заинлайненная рекурсия. А всё, что компилятор не тянет (фабрики, property-инъекция, инъекция контейнера, циклы), честно откатывается на путь с обёрткой на узел / интерпретатор. Так что это скорее гибрид, чем одна мегафункция.

Соглашусь, на глубоких или широких транзиентных графах сгенерированная функция растёт, и компиляция обёртки на конструктор (как у вас) заметно лучше композится с кэшем, обработкой ошибок, инструментацией, будущими фичами и тд. Трейсбэк в плоской функции тоже менее гранулярный. Я оптимизировал узкий частый случай и оставил фоллбэк, но за гибкость это плата.

Спасибо, что навели на dishka, допишу в бенчмарк и вернусь с цифрой.

А можете подробнее про вашу обёртку на конструктор? Это кодген через exec или сборка замыкания?

[Tishka17]

А, ну я всегда рассматривал transient как "костыль", которым никто не пользуется, ведь scoped объекты ничем не хуже, зато точно можно переиспользовать в скоупе. Надо будет повнимательнее посмотреть на ваш код, вызвана скорость отсутствием фич или конкретными механиками, уж действительно быстро вышло

Я в dishka генерирую код на python и через exec преобразую. Это позволяет вырезать всякие ветки и разворачивать циклы. Например, так нет огранения на количество параметров функции (я вижу у вас отдельно расписаны варианта до 4)

[VShulcz]

По механике мы в одну сторону смотрим - разница в том, что вы кодгените обёртку на конструктор, а я всю транзиентную цепочку разом.

Про transient как "костыль":
- у вас скоуп-центрично: scoped переиспользуется в скоупе, и этого достаточно.
- у меня lifetime-центрично (singleton/transient/scoped), и transient - новый на каждый вызов.

Не возьмусь утверждать, что лучше. Ваш "scoped ничем не хуже" - вполне рабочий аргумент.

Прогнал dishka на том же графе: manual 0.264, injex 0.407, dishka 0.755, wireup same-scope 0.935, dependency-injector 1.721. Конечно, важна оговорка: граф синхронный, и сила dishka в async-ресурсах и явных scope, которых тут нет.

[Genius_Russian_Coders]

Отлично. Интересно, как exec-кодогенерация работает с slots и frozen dataclass? Прямая установка атрибутов там ломается. И планы на async резолв для FastAPI?

[VShulcz]

Со slots и frozen dataclass кодген работает нормально: генерится cls(dep0, dep1, …), объект создаётся через обычный init/dataclass-init, и Injex ничего не присваивает в инстанс напрямую.

Но все такие ломается одно - property-инъекция: она делает setattr после конструирования, поэтому на frozen происходит FrozenInstanceError, на slots - AttributeError: no dict. Тут дело не в кодгене, так упадёт любой setattr подход. Для slots/frozen нужно брать конструкторную инъекцию, а property-инъекцию там просто не применять))

Резолв сейчас синхронный. Для FastAPI можно: собрать контейнер один раз в lifespan и резолвить синхронно, а async живёт внутри методов уже собранных сервисов, а не на этапе конструирования, так что для обычной проводки async-резолв не нужен. Чего Injex сознательно не делает, так это управление жизненным циклом async-ресурсов, тут dishka/dependency-injector сильнее. Полноценный async-резолв с ресурсами запланирован на будущее.

[Tishka17]

exec-кодогенерация не меняет подход к созданию объектов, она позволяет делать инайлнинг, вырезание веток и разворачивание циклов.

Условно, до кодгена был такой код

res = cls(*(container.get(d) for d in deps))
if cached:
    cache[cls] = res

то, имея cached=False, а deps=[int, str, A], мы можем вырезать иф, убрать распаковку и сгенерировать

res = cls(container.get(int), container.get(str), container.get(A))

Резвол асинк зависимостей в dishka есть, то я бы рекомендовал с этим быть осторожнее. С большой вероятностью (вероятно не всегда), если вы делает async-вызов при создании ресурса, вы смешиваете бизнес логику и просто получение зависимости. При этом я понимаю, что избежать async вызова при финализации ресурса будет сложнее