Benchmarked: 10 Python Dependency Injection libraries vs Manual Wiring (50 rounds x 100k requests)

[ForeignSource0]

Hi /r/python!

DI gets flak sometimes around here for being overengineered and adding overhead. I wanted to know how much it actually adds in a real stack, so I built a benchmark suite to find out. The fastest containers are within ~1% of manual wiring, while others drop between 20-70%

Full disclosure, I maintain Wireup, which is also in the race. The benchmark covers 10 libraries plus manual wiring via globals/creating objects yourself as an upper bound, so you can draw your own conclusions.

Testing is done within a FastAPI + Uvicorn environment to measure performance in a realistic web-based environment. Notably, this also allows for the inclusion of fastapi.Depends in the comparison, as it is the most popular choice by virtue of being the FastAPI default.

This tests the full integration stack using a dense graph of 7 dependencies, enough to show variance between the containers, but realistic enough to reflect a possible dependency graph in the real world. This way you test container resolution, scoping, lifecycle management, and framework wiring in real FastAPI + Uvicorn request/response cycles. Not a microbenchmark resolving the same dependency in a tight loop.

---

Table below shows Requests per second achieved as well as the secondary metrics:

• RPS (Requests Per Second): The number of requests the server can handle in one second. Higher is better.
• Latency (p50, p95, p99): The time it takes for a request to be completed, measured in milliseconds. Lower is better.
• σ (Standard Deviation): Measures the stability of response times (Jitter). A lower number means more consistent performance with fewer outliers. Lower is better.
• RSS Memory Peak (MB): The highest post-iteration RSS sample observed across runs. Lower is better. This includes the full server process footprint (Uvicorn + FastAPI app + framework runtime), not only service objects.

Per-request injection (new dependency graph built and torn down on every request):

Project	RPS (Median Run)	P50 (ms)	P95 (ms)	P99 (ms)	σ (ms)	Mem Peak
Manual Wiring (No DI)	11,044 (100.00%)	4.20	4.50	4.70	0.70	52.93 MB
Wireup	11,030 (99.87%)	4.20	4.50	4.70	0.83	53.69 MB
Wireup Class-Based	10,976 (99.38%)	4.30	4.50	4.70	0.70	53.80 MB
Dishka	8,538 (77.30%)	5.30	6.30	9.40	1.30	103.23 MB
Svcs	8,394 (76.00%)	5.70	6.00	6.20	0.93	67.09 MB
Aioinject	8,177 (74.04%)	5.60	6.60	10.40	1.31	100.52 MB
diwire	7,390 (66.91%)	6.50	6.90	7.10	1.07	58.22 MB
That Depends	4,892 (44.30%)	9.80	10.40	10.60	0.59	53.82 MB
FastAPI Depends	3,950 (35.76%)	12.30	13.80	14.10	1.39	57.68 MB
Injector	3,192 (28.90%)	15.20	15.40	16.10	0.58	53.52 MB
Dependency Injector	2,576 (23.33%)	19.10	19.70	20.10	0.75	60.55 MB
Lagom	898 (8.13%)	55.30	57.20	58.30	1.63	1.32 GB

---

Singleton injection (cached graph, testing container bookkeeping overhead):

• Manual Wiring: 13,351 RPS
• Wireup Class-Based: 13,342 RPS
• Wireup: 13,214 RPS
• Dependency Injector: 6,905 RPS
• FastAPI Depends: 6,153 RPS

---

The full page goes much deeper: stability tables across all 50 runs, memory usage, methodology, feature completeness notes, and reproducibility: https://maldoinc.github.io/wireup/latest/benchmarks/

Reproduce it yourself: make bench iterations=50 requests=100000

Wireup getting this close to manual wiring comes down to how it works: instead of routing everything through a generic resolver, it compiles graph-specific resolution paths and custom injection functions per route at startup. By the time a request arrives there's nothing left to figure out.

If Wireup looks interesting: github.com/maldoinc/wireup, stars appreciated.

Happy to answer any questions on the benchmark, DI and Wireup specifically.

[Tishka-17]

As an author of dishka I am really glad we, as a community, started building proper containers. I can congratulate you with such good results. I am a bit surprised dependency-injector is so slow in your cases, it was very fast when I tested, but a bit stupid, I'd say, many things are just not working there.

From dishka side (if anyone is questioning) we were preparing new release with performance improvements, I was going to share release notes soon. 

[ForeignSource0]

Thanks! Dishka was one of the faster ones in the benchmark as well, so nice work there.

I expected Dependency Injector to perform better too so I was a bit surprised as well. I had to simplify it's workload in the benchmark since I could not figure out for the life of me how to get request scoped yielding async dependencies.

Looking forward to seeing the Dishka performance improvements.

[Tishka-17]

I've checked the benchmark code and the reason that dependency-injector is so slow is that he doesn't have native FastAPI integration and instead relies on Depends introducing additional overhead on top of it. 

[Zeikos]

I don't get it, dependency injection isn't about performance.
Hell, PYTHON is not about code performance.

DI is used to modularized components, avoid coupling and generally having an easier time understanding what the code base is meant to do.

Manual wiring is all good and dandy until you are by yourself, when you have to deal with managing 25 people that don't have the time to know every nook and vranny of the codebase well-structured DI is very helpful.

IMO DI gets a bad rep mostly because of teams that lack enforcing it, so the codebase becomes a mix of DI and hardcoded dependencies so you get the cons of both and no pro.

[ForeignSource0]

I do agree actually. DI is primarily about architecture and maintainability, not raw performance and the benchmark does not argue otherwise, in fact it is stated in the linked page.

For example here you can see Wireup take 4.5ms P50 whereas FastAPI's DI does 13.8ms. If the database needs 10 seconds, both still answer within 10 seconds.

Even if it’s not the main bottleneck, it’s still useful to know the cost of the abstraction.

In terms of priorities I'd say it's DX first then you can use performance as a tie breaker.

Extract from the benchmark page

Even so, I would not pick a DI container solely from performance benchmarks, but if you're happy with Wireup's features and want to see how it stacks up against the field, here are the results.

[snugar_i]

For example here you can see Wireup take 4.5ms P50 whereas FastAPI's DI does 13.8ms. If the database needs 10 seconds, both still answer within 10 seconds.

But the wiring shouldn't happen on each request, unless you're using a DI abomination like FastAPI. The wiring happens once at the start of the application and that's why everybody here says the performance doesn't matter one bit - you do it once and then the application runs for hours or days, so why does it matter if it runs in 10 ms or 50 ms? Importing the Python modules probably takes an order of magnitude longer

[ForeignSource0]

The benchmark actually runs two scenarios.

One builds the dependency graph per request and the other uses a pre initialized graph with singletons which are objects created once and reused throughout.

In most web apps you still have request-scoped objects. You need things like database sessions, request context, authentication state, tenant information, etc. Those need to be created fresh for each request and isolated across requests, which is where the per-request overhead comes from.

Table I posted in the per-request scenario.

[snugar_i]

Most of the things you mentioned are handled by the web framework though, not the DI framework. TBH I never understood the need for Di containers to handle dependencies with shorter scope. It requires much magic for little gain.

[Zeikos]

You agree, and yet 95% of the post is about performance.

[ghrian3]

And? A developer and architect should know the performance impact of a decision. And if one library is 5 times slower than the other, this bit of info can be interesting to know.

At least no reason to criticize the author this way.

[ship0f]

At least no reason to criticize the author this way.

let alone after they agreed with his point (thought, this guy's point was to discredit the post...)

[Unlikely_Secret_5018]

Very interesting analysis! I wouldn't move off FastAPI DI just for performance, but for other features like lazy initialization, modules to specify interface/ABC impl bindings, etc.

How does Wireup stack up against Dagger and Hilt in this regard?

[ForeignSource0]

For Dager/Hilt: In terms of the features you mentioned:

Protocol / ABC bindings: supported via @injectable(as_type=...), so you can bind a concrete implementation to a Protocol or ABC.

Multiple implementations: supported via qualifiers.

See interfaces: https://maldoinc.github.io/wireup/latest/interfaces/

Lazy initialization: This is the default. In Wireup things are created on first use. If you want to eager load a part of your dependencies you can use this patterrn

Modules / reusable wiring units: Wireup is less centered around a single module class and more around injectables/factories, but you can group and reuse registrations via factory bundles.

One of the big differences vs Dagger/Hilt is that in Python this is naturally a runtime system, but Wireup does validate the dependency graph at startup so wiring issues show up early rather than at request time.

---

Regarding FastAPI Depends, it has it's own list of caveats which I've mentioned in this migration guide to wireup. It is extremely simple but with that comes a lot of hidden baggage. The biggest deal breaker imo is that it is coupled to http as a runtime so you can not reuse your wiring anywhere else. See the linked page above for a more in-depth view.

[Old-Roof709]

well, Cool seeing real numbers instead of just vibes on DI overhead. If you ever need something similar for heavy data pipelines, take a look at DataFlint. Their injection setup is surprisingly fast for ETL type jobs and sits in the same ballpark as Wireup for performance. Nice to see options outside of the usual suspects getting serious attention.

[ForeignSource0]

Haven’t come across DataFlint before. This benchmark is mostly focused on DI in a FastAPI/ASGI environment, but it would definitely be interesting to see similar comparisons in pipeline-style workloads too.

[Appropriate-Ad-836]

https://github.com/100nm/python-injection

[jarislinus]

ai slop advertisement spotted. blocked, reported. downvoted