You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 19, 2023. It is now read-only.
Having identified ConcurrentDictionary as being one of (but not the only) bottleneck, despite its very good performance, I've come up with a new solution which is valid for long-lived objects, such as containers (and, potentially, root target containers).
It requires adding specific TFMs to Rezolver for the runtimes which support System.Reflect.Emit APIs such as AssemblyBuilder, TypeBuilder etc - and leverages the static field initialisers to initialise objects statically which would either:
need to be created each time a call is made, but which vary only by a type (which can, therefore, be used as generic arguments
use the standard ConcurrentDictionary pattern of a thread-safe GetOrAdd()
Using static initialisers of dynamic types automatically provides thread-safe initialisation but without any performance penalty for accessing the protected data on subsequent reads. Just applying this pattern to both ResolveContext and the ICompiledTarget for strong-typed Resolve operations has provided a big reduction in memory overhead and performance.
The text was updated successfully, but these errors were encountered:
Having identified ConcurrentDictionary as being one of (but not the only) bottleneck, despite its very good performance, I've come up with a new solution which is valid for long-lived objects, such as containers (and, potentially, root target containers).
It requires adding specific TFMs to Rezolver for the runtimes which support
System.Reflect.Emit APIs
such asAssemblyBuilder
,TypeBuilder
etc - and leverages the static field initialisers to initialise objects statically which would either:Using static initialisers of dynamic types automatically provides thread-safe initialisation but without any performance penalty for accessing the protected data on subsequent reads. Just applying this pattern to both
ResolveContext
and theICompiledTarget
for strong-typed Resolve operations has provided a big reduction in memory overhead and performance.The text was updated successfully, but these errors were encountered: