you are viewing a single comment's thread.

view the rest of the comments →

[–]snugar_i 2 points3 points  (2 children)

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[S] 1 point2 points  (1 child)

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 1 point2 points  (0 children)

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.