Improve performance of ActivatorUtilities.CreateInstance

Currently, it’s 30x slower than invoking factory delegate. While it could never reach the performance of invoking the factory delegate there is a lot of possible improvements (especially around allocations) in ActivatorUtilities.CreateInstance

[Yves57]

@pakrym Here is a snapshot of the allocated memory when allocating 10000 objects with ActivatorUtilities.CreateInstance() (with the official “2.2.0” DependencyInjection package). I have crossed out the allocations optimized with the last PR. It remains:

• ConstructorInfo[] -> I don’t see any possible optimization. But I may be wrong.
• ParameterInfo[] -> I don’t see any possible optimization. But I may be wrong.
• The object[] allocated in the ConstructorMatcher constructor. We may imagine reuse the array during the matching loop. But this optimization would be valid only if there is more than two constructors, and if the constructors have same number of parameters (ConstructorInfo.Invoke() requests a parameter array of the exact length). So it seems very restrictive.

But there is maybe a more generic but trickier optimization here. The method CheckArguments is called RuntimeConstructorInfo.Invoke() (see the orange rectangle). A copy of the parameters is done because they may be changed by CheckValue(). But CheckValue() seems to returns the object as-is in the normal case. So we could imagine a lazy allocation of the copyOfParameters array only if the parameter is changed by CheckValue(). The advantage is that any object construction (and maybe other reflection calls) could benefit of this optimization. But the optimization seems too big to be correct. I suppose that something is wrong in my analysis 😃.

[analogrelay]

TIL that it’s the person who merges the PR that gets credit for closing linked issues ;P.

Sounds good, thanks for filing that issue @Yves57 !