Про DI в Python вечно всплывает один и тот же спор: контейнер — это лишний оверхед, протащи зависимость в конструктор руками и не выдумывай. Звучит логично, я и сам так долго считал. Но логично — не число, поэтому в какой-то момент я сел и замерил: во что на самом деле обходится контейнер, когда резолвишь граф по кругу, и можно ли вообще догнать ручную сборку, не сломав при этом семантику.

Спойлер: подойти вплотную можно. Но интереснее тут не финальная цифра, а дорога к ней — почти каждый шаг пригодится и за пределами DI. Как ловить микрооверхед, который не виден в одном вызове. Как не бояться выкидывать код, который и так никогда не выполняется. И как не дать exec-кодогенерации молча сломать прод.

Стенд

Граф маленький, но жизненный для бэкенда: сверху синглтоны — конфиг и клиент, ниже транзиентные репозиторий, отправщик писем и аудит, и use-case RegisterUser, который тянет все три. Бенчмарк гоняет повторный резолв этого графа по кругу; рядом, как нижняя граница, — те же объекты, собранные руками. Машина одна и та же на всех замерах. Числа синтетические и завязаны на форму графа.

Отсчёт оказался отрезвляющим: руками — 0.27 мкс на операцию, наивный контейнер — 52.9. Почти в двести раз медленнее. Чтобы было ясно, что цифра взята не с потолка: punq, обычный рефлексивный контейнер, на том же графе даёт около 57 мкс. Так и выходит, если разбирать конструкторы на каждый вызов.

Откуда берутся 53 микросекунды

Наивный резолвер на каждый вызов лезет в конструктор: берёт inspect.signature, дёргает get_type_hints, по аннотациям рекурсивно достаёт зависимости и создаёт объект. Беда в том, что get_type_hints и разбор сигнатуры — дорогие: там вычисление аннотаций, обход MRO, аллокации. Один раз — ладно. Миллион раз нподряд — десятки+ микросекунд.

Напрашивается очевидное: разобрать граф один раз. При регистрации (или на первом резолве) читаем конструктор и складываем план: какие зависимости, в каком порядке, с каким временем жизни. Дальше резолв идёт по плану, без signature и get_type_hints вообще.

Один этот шаг убирает почти весь оверхед: 52.9 → 0.818 мкс, примерно в 65 раз. А дальше начинается то, что обычно уже не трогают.

Поворот первый: проверка, которая не могла сработать

Когда план закэширован, каждый быстрый конструктор оборачивался в защиту от циклов:

def create(scope):
    if cls in resolving:                 # защита от цикла
        raise CyclicDependencyException(cls)
    resolving.add(cls)
    try:
        return cls(dep0(scope), dep1(scope))
    finally:
        resolving.remove(cls)

Проверка множества, вставка, try/finally — на каждый узел и на каждый резолв. Кажется, без этого никак. Но есть нюанс: быстрый конструктор вообще создаётся только тогда, когда подграф уже доказанно без циклов. На этапе сборки плана, наткнувшись на цикл, компилятор возвращает None, и такой граф уходит на медленный интерпретируемый путь — там проверка и живёт. То есть на быстром пути условие cls in resolving не может выполняться никогда.

Это защита, которая физически не срабатывает. Я убрал её с быстрого пути; ловля циклов осталась там, где реально работает, — в интерпретаторе и в отдельной проверке графа. Циклический граф просто не получает быстрый конструктор и отлавливается как раньше. Минус несколько процентов на ровном месте.

Аллокация на каждый вызов

Профайлер подсветил ещё одну мелочь, которая дорого выходит из-за частоты. Сам resolve(Тип) для самого частого случая — резолв по типу, без имени и без скоупа — собирал ключ-кортеж (interface, None) и читал пару атрибутов регистрации. На один вызов — наносекунды, но вызовов миллионы. Прямой словарь тип → конструктор для этого случая (сбрасывается, когда меняются регистрации или включается тест-оверрайд) убирает и аллокацию кортежа, и лишние чтения.

Поворот второй: компилируем граф — и чуть не ломаем прод

Главный запас прятался в форме самого быстрого пути. Транзиентный граф собирался в дерево вложенных замыканий: резолв use-case дёргал замыкание use-case, оно — замыкание репозитория, оно — геттер синглтон-клиента. По вызову функции на каждый узел. Хуже того, общий синглтон, нужный двум соседям сразу, доставался дважды.

Лечится так: склеить всю цепочку транзиентных зависимостей в одну плоскую функцию — заинлайнить конструкторы и посчитать каждый общий синглтон один раз вместо двух. По сути — то, что в компиляторах зовут устранением общих подвыражений (CSE).

То есть это кодогенерация: по плану графа я собираю текст функции и поднимаю его через exec в замыкании с нужными символами. Листья — синглтоны, скоупы, инстансы — остаются прежними конструкторами (логику кэширования и отложенного создания у них не трогаю, беру как есть); плоской становится только транзиентная часть, ровно то, что крутится на каждом резолве. В сгенерированный текст не попадает ни одного имени класса или пользовательского значения — только служебные сгенерированные имена, так что подсунуть туда через исходник нечего.

Это и дало главный выигрыш: 0.818 → 0.401 мкс. От наивной версии — около 130 раз; теперь контейнер отстаёт от ручной сборки меньше чем в полтора раза.

И вот тут я чуть не затормозил. exec-кодогенерация в библиотеке — это риск особого сорта. Баг в ней не упадёт стектрейсом. Он молча соберёт не тот объект в проде: подсунет не ту реализацию, потеряет общий синглтон, перепутает порядок аргументов.

Поэтому катить на глаз я не стал и сделал фаззинг на эквивалентность. Смысл простой: генерим тысячи случайных графов без циклов, с разными временами жизни, опциональными и дефолтными параметрами; каждый граф резолвим двумя путями — скомпилированным и отдельным, нарочно тупым эталонным резолвером; и сравниваем не значения, а структуру результата. Те же классы и та же картина общих ссылок: где синглтон обязан быть одним объектом, где транзиент — разными.

4000 случайных графов — структура совпала на каждом

Чего компилятор не умеет — фабрики, property-инъекцию, инъекцию самого контейнера, циклы — он честно отдаёт None и откатывается на старый путь. Ровно эта проверка, а не вроде правильно, и есть причина, почему exec-код вообще доехал до релиза.

Честно про границы

Чтобы не создавать ложного ощущения. Числа синтетические и завязаны на форму графа: с кучей скоупов, асинхронными ресурсами или фабриками картина будет другой. Плоская компиляция ускоряет именно цепочки транзиентов с общими синглтонами; если почти везде фабрики или property-инъекция, выигрыша не будет — такие узлы и так идут по интерпретируемому пути. И ниже ~0.4 мкс в чистом Python без C-расширения уже не уехать, а это другой разговор про зависимости.

Итог

Делал я это в рамках небольшого типизированного DI-контейнера, который веду (код и бенчмарк открыты — github.com/vshulcz/injex), если захочется покопаться в деталях. Но ценнее тут, сами приёмы.

Проголосовал 1 пользователь. Воздержавшихся нет.