Про 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-расширения уже не уехать, а это другой разговор про зависимости.
Итог
Версия | Резолв, мкс/оп | Что изменилось |
|---|---|---|
руками | 0.271 | нижняя граница |
наивный контейнер | 52.9 | рефлексия на каждом резолве |
+ кэш плана | 0.818 | разбор конструкторов один раз |
+ плоская функция, CSE, словарь-диспетчер | 0.401 | компиляция графа |
Делал я это в рамках небольшого типизированного DI-контейнера, который веду (код и бенчмарк открыты — github.com/vshulcz/injex), если захочется покопаться в деталях. Но ценнее тут, сами приёмы.
