docs: regenerate the performance tables for 4.0 (#578)

[lesnik512]

Closes #578.

Summary

Regenerated the comparative tables in docs/introduction/performance.md with just bench-report (5 runs) at main f300c2e, after every 4.0 code change landed. The machine, CPython build and rival pins match the 3.x publication at 630de77: Apple M2, macOS 26.6.2, CPython 3.14.7 with the GIL, dishka 1.10.1, dependency-injector 4.49.1, that-depends 4.1.0, wireup 2.12.0. So the absolute times compare as well as the ratios. Every cell's across-run IQR is at most 4.3%.

Numbers

	3.x (630de77)	4.0 (f300c2e)
C1 transient, by reference	253 ns	242 ns
C2 warm singleton, by reference	151 ns	146 ns
C3 deep chain, by reference	789 ns	760 ns
C4 request lifecycle	2.29 µs	2.28 µs
C4 vs that-depends / dishka / wireup	0.18 / 1.08 / 0.14	0.18 / 1.12 / 0.14
C6 context	1.45 µs	1.09 µs
C6 vs dependency-injector / that-depends	0.38 / 0.48	0.28 / 0.36
C6 vs dishka / wireup	1.15 / 1.02	0.88 / 0.78

• C6 fell 25%. The guard tier points the same way: G9 fell 28% with feat!: require context values unless ContextProvider sets default= #557 and 5.9% more with perf: cheaper request cycle and cold path (#573) #585. modern-di is now faster than all four rivals on C6. In 3.x it was slower than dishka and level with wireup.
• C4 is flat. On G7, perf: cheaper request cycle and cold path (#573) #585's −2.9% and fix!: lock each cached factory on its own and build its dependencies under that lock (#569) #597's +4.6% roughly cancel. The dishka C4 ratio rose because dishka's own cell is about 3% lower. modern-di's cell did not move.
• C1 to C3 fell 3 to 4% on both sides. The rival absolutes implied by the 3.x ratios are within about 2% of this run. The page names fix!: match scopes by enum member, not by integer value (#572) #596's == to is scope check as the likely cause, since it measured about 5 ns per same-scope resolve in that PR. It also says no guard run isolated the change.

Narrative changes

• The results header names f300c2e as the 4.0 code, unreleased when measured. Relabel it to the tag once 4.0 ships, as docs(performance): name the release the snapshot ships in #500 did for docs(performance): republish the comparative tables after the template resolver #471.
• "What the numbers show": every figure comes from the new tables. The C6 bullet now says modern-di leads all four rivals. The prose numbers that depend on the tables are updated: the by-type vs by-reference cells, the dishka C4 ratio, the implied dependency-injector cache hit (about 66 ns), the that-depends C1 series, and the event-loop floor's share of C4. That share is 14%, from a G7c run on this commit: 31.8 µs per batch, so 0.32 µs per request.
• "What moved in this publication" now compares 4.0 against 630de77.
• The 4.0 part of "Why the results look this way" no longer says the tables show the 3.x publication. It covers feat!: require context values unless ContextProvider sets default= #557, perf(alias): bind an Alias to its source at compile time #559, feat!: remove Container(use_lock=) #561, perf: cheaper request cycle and cold path (#573) #585, refactor: compose resolver templates and build resolution steps on the provider (#574) #593 (no change), fix!: match scopes by enum member, not by integer value (#572) #596 and fix!: lock each cached factory on its own and build its dependencies under that lock (#569) #597, and every guard figure in it is quoted from that PR's body. The fix!: lock each cached factory on its own and build its dependencies under that lock (#569) #597 paragraph keeps the figures that PR wrote and now cites the PR instead of issue Tree-wide cache lock: cross-thread deadlock and per-thread dependency builds #569.
• The paragraph after the feat: generate Factory resolvers from a source template; compile overrides in #470 table referred to "the C4 and C6 movement above", meaning the 3.x section this PR replaces. It now gives the 3.x movement directly.
• C6 caveat: in 4.0, open() only resets a flag and no longer takes a lock. The 81 ns and 110 ns figures are now described as what they were when C6 was first published.

Design decisions

• Rival pins are unchanged, as in docs(performance): republish the comparative tables after #540, #541 and #542 #543. Bumping a rival inside a docs republish would mix two changes in one diff.
• No other page quotes these figures. I grepped README.md, docs/ and AGENTS.md for every old cell.
• benchmarks/README.md is guidance for the guard tier and is not touched.

Test plan

• just bench-report (5 runs) at f300c2e, tables pasted verbatim
• just lint and just lint-ci clean
• just test-ci: 626 passed, 100% coverage. No code changed.
• mkdocs build --strict clean

[github-actions]

Benchmark

Details

Benchmark suite	Current: 5fe11b7	Previous: f300c2e	Ratio
benchmarks/test_guard_by_type.py::test_g16_resolve_by_type	3963060.7859819843 iter/sec (stddev: 1.2120269633479376e-8)	3170062.739027931 iter/sec (stddev: 9.642531243257344e-9)	0.80
benchmarks/test_guard_by_type.py::test_g17_resolve_by_type_large_registry	3975643.300809753 iter/sec (stddev: 9.5167633769716e-9)	3105980.4317636467 iter/sec (stddev: 1.0472467861574959e-8)	0.78
benchmarks/test_guard_cold.py::test_g8_cold_first_resolve	22538.187968839105 iter/sec (stddev: 0.00006770415868767959)	20973.655216960145 iter/sec (stddev: 0.000055223371557473146)	0.93
benchmarks/test_guard_cold.py::test_g8b_cold_first_resolve_cached	17735.311275406202 iter/sec (stddev: 0.00018591399861868845)	16010.280855285222 iter/sec (stddev: 0.00013081285983659776)	0.90
benchmarks/test_guard_concurrency.py::test_g14_concurrent_cached_hit[1]	506.0224065981012 iter/sec (stddev: 0.0000396259716187068)	445.0689078221753 iter/sec (stddev: 0.00005354522864359469)	0.88
benchmarks/test_guard_concurrency.py::test_g14_concurrent_cached_hit[2]	476.0504898810812 iter/sec (stddev: 0.00003229276488986819)	418.10698817170345 iter/sec (stddev: 0.00003800367849990269)	0.88
benchmarks/test_guard_concurrency.py::test_g14_concurrent_cached_hit[4]	432.42177291236044 iter/sec (stddev: 0.000028592001359521155)	379.4708988394154 iter/sec (stddev: 0.00003666195211942698)	0.88
benchmarks/test_guard_concurrency.py::test_g15_concurrent_first_resolve[1]	1999.72767041867 iter/sec (stddev: 0.00016786323683998992)	1808.7122776493813 iter/sec (stddev: 0.00016049663523896344)	0.90
benchmarks/test_guard_concurrency.py::test_g15_concurrent_first_resolve[2]	1590.7515191381024 iter/sec (stddev: 0.0001685664695097343)	1416.5690916173216 iter/sec (stddev: 0.0002353180404157794)	0.89
benchmarks/test_guard_concurrency.py::test_g15_concurrent_first_resolve[4]	1106.6955904015804 iter/sec (stddev: 0.00018081457397504876)	939.1878305927596 iter/sec (stddev: 0.0002819724115896676)	0.85
benchmarks/test_guard_concurrency.py::test_g15b_concurrent_first_resolve_sibling_children[1]	1965.9874343924942 iter/sec (stddev: 0.00019677691738943483)	1505.4395671529771 iter/sec (stddev: 0.00023078371432772946)	0.77
benchmarks/test_guard_concurrency.py::test_g15b_concurrent_first_resolve_sibling_children[2]	1179.2237867518459 iter/sec (stddev: 0.0013947712665808578)	1095.1187972554367 iter/sec (stddev: 0.0012572361036121494)	0.93
benchmarks/test_guard_concurrency.py::test_g15b_concurrent_first_resolve_sibling_children[4]	844.0539556990094 iter/sec (stddev: 0.00018263828764097353)	768.0738481501177 iter/sec (stddev: 0.00024333515727099846)	0.91
benchmarks/test_guard_lifecycle.py::test_g6_build_child_container	961091.9927216569 iter/sec (stddev: 3.452004225771381e-8)	795855.8195767066 iter/sec (stddev: 2.8440295591758545e-7)	0.83
benchmarks/test_guard_lifecycle.py::test_g6b_build_child_container_auto_scope	929611.1023078061 iter/sec (stddev: 2.4807894838309807e-8)	856767.7336291238 iter/sec (stddev: 4.376204267038924e-8)	0.92
benchmarks/test_guard_lifecycle.py::test_g7_request_lifecycle_batch	2432.981421536469 iter/sec (stddev: 0.000009710434906546652)	2317.463144376915 iter/sec (stddev: 0.00002035335306793147)	0.95
benchmarks/test_guard_lifecycle.py::test_g7c_event_loop_floor_control	58785.46691915621 iter/sec (stddev: 0.000001361146783882081)	57653.90481538115 iter/sec (stddev: 0.00000238195404196344)	0.98
benchmarks/test_guard_lifecycle.py::test_g7b_request_cycle_sync	299831.64453126444 iter/sec (stddev: 1.5162070252185915e-7)	286143.5132476302 iter/sec (stddev: 9.237828330669941e-8)	0.95
benchmarks/test_guard_lifecycle.py::test_g13_teardown_at_scale	41696.74301045085 iter/sec (stddev: 0.0000015399733839263313)	39492.38178026401 iter/sec (stddev: 0.0000022065222464510984)	0.95
benchmarks/test_guard_lifecycle.py::test_g13b_teardown_at_scale_async_no_finalizers	471.04000287277074 iter/sec (stddev: 0.001089380821792638)	454.6109336458674 iter/sec (stddev: 0.0008030486625371973)	0.97
benchmarks/test_guard_resolve.py::test_g1_transient_resolve	2395071.7566637713 iter/sec (stddev: 2.677534564392578e-8)	2142536.068517913 iter/sec (stddev: 2.3321872385231816e-8)	0.89
benchmarks/test_guard_resolve.py::test_g2_cached_resolve	3872147.272947003 iter/sec (stddev: 1.2266696539700055e-8)	3062074.090369667 iter/sec (stddev: 1.2358042180412772e-8)	0.79
benchmarks/test_guard_resolve.py::test_g3_deep_chain	802494.3933218106 iter/sec (stddev: 7.793557359526441e-8)	699179.3941212147 iter/sec (stddev: 4.5433966098214043e-8)	0.87
benchmarks/test_guard_resolve.py::test_g4_wide_resolve	481473.48991314275 iter/sec (stddev: 4.2839505140645426e-7)	446210.4462325217 iter/sec (stddev: 3.944569902792762e-7)	0.93
benchmarks/test_guard_resolve.py::test_g5_cross_scope	2113225.5693969084 iter/sec (stddev: 3.607936023686703e-8)	1973383.594098137 iter/sec (stddev: 2.27451395970113e-8)	0.93
benchmarks/test_guard_resolve.py::test_g9_context_resolve	1565752.606396446 iter/sec (stddev: 1.6024514415854065e-7)	1314845.4665418933 iter/sec (stddev: 1.5516940522380182e-7)	0.84
benchmarks/test_guard_resolve.py::test_g12_override_active_resolve	819174.7175144735 iter/sec (stddev: 3.8869206195548145e-8)	733413.2093663714 iter/sec (stddev: 5.088316483973963e-8)	0.90
benchmarks/test_guard_resolve.py::test_g18_alias_hop	3872039.1726534087 iter/sec (stddev: 9.174045287333113e-9)	3353456.419264143 iter/sec (stddev: 1.499165792076636e-8)	0.87
benchmarks/test_guard_validate.py::test_g10_validate_deep_chain	26490.895454547684 iter/sec (stddev: 0.0002849367283486264)	24718.151687374368 iter/sec (stddev: 0.00019215123662163076)	0.93
benchmarks/test_guard_validate.py::test_g11_validate_wide	17604.76286296453 iter/sec (stddev: 0.000027075835987755574)	16201.651632010124 iter/sec (stddev: 0.000026202133812871022)	0.92

This comment was automatically generated by workflow using github-action-benchmark.