What does performance benchmarks do? #1795
-
I read some performance reports of inversify in like https://inversify.io/blog/announcing-inversify-7-0-0-alpha-5-prerelease/, but I'm wondering what the benchmark is doing. For example, the first one 'Get service in singleton scope' in the linked blog. I tested some simple stuff, like to register 1000 singleton bindings and get all the instances using inversify 6.0.1 and 7.5.1, but the time elapsed doesn't show much difference. (Like 8ms for the bindings and 15ms for the resolvings) Does inversify increase its performance on this kind of first-time resolving of singletons compared to 6.x versions? Thanks. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Hey @GarfieldJiang, benchmarks are available here.
It should, but that's not reflected in the benchmarks. I don't expect a big boost in that case. The only advantages 7.x has in that scenario are better internal data structures. This means some internal binding searches are now indexed and way less objects are used. In low execution time flows it means the GC takes less time to allocate and free resolve related objects. A better use of the GC is relevent in these flows and that is the reason to believe there is probably a small performance boost. The main performance boost is the use of a planning cache. If a binding is only instantiated once the container does not receive that performance boost.
Bindings are not a concern, it's such a simple operation there's no way it's slow. Regarding resolutions, there should be no big performance boost for the reasons already mentioned. |
Beta Was this translation helpful? Give feedback.
Hey @GarfieldJiang, benchmarks are available here.
Get service in singleton scope
does that: resolves the same singleton scoped binding multiple times.It should, but that's not reflected in the benchmarks. I don't expect a big boost in that case. The only advantages 7.x has in that scenario are better internal data structures. This means some internal binding searches are now indexed and way less objects are used. In low execution time flows it means the GC takes less time to allocate and free resolve related objects. A better use of the GC is relevent in these flows and …