Root Services

[seesharper]

The problem is that the number of root services (services resolved directly from the container) grow gradually as the various benchmarks are executed. Most containers have some kind of dictionary that maps a service type to the delegate that represents resolving the service. When we talk about the top performing containers, looking up this delegate is actually what sets them apart. Some use a simple dictionary while others use a more optimized structure such as a binary search tree.

The first test is Singleton and after warmup we will have 3 root services, ISingleton1, ISingleton2 and ISingleton3. For the next test which is Transient we will have 6 root services, ITransient1, ITransient2 and ITransient3 in addition to the 3 services from the singleton test.

This means that service lookop will gradually cost more and more as the runner loops through the tests.

When the test runner reaches the last test the container will have root services for all services retrieved through the IContainerAdapter.Resolve method. Sort of a before all warmup.

I think the best solution would be to run all the benchmarks at startup so that all root services has been resolved once before starting the main run.

This also makes for a more real-life scenario as it is not unusual to have quite a few root services in a container.

[ipjohnson]

I like @seesharper idea, the only caveat to all this is that containers that actually have more features and compete in more benchmarks end up at a slight disadvantage compared to containers that don't compete in all. If we went this way maybe we could some how add extra registrations (and resolve them) for containers that don't compete in all so they don't get an advantage.

I spend most of my time these days in ASP.Net core web apps, to give an example roughly 30 types are resolved from the container before the first controller is even created. If you're doing custom controller and view activation the number of types being resolved can grow rather large for big applications.

[dotnetjunkie]

I agree with this analysis. Daniel would probably be thrilled to see a pull request :)

[seesharper]

@danielpalme What do you think? Would you accept a pull request to fix this?

[danielpalme]

Sure. Let's see if this really makes a big difference.

[danielpalme]

Merged pull request #72

[jzabroski]

Hi Ian,

Could you explain to me a bit more what you mean by custom controller and view activation?

For view activation, I think you're just talking about subclass ing RazorViewEngine class and then of course providing concrete implementation for its constructor arguments i.e. IRazorPageFactory, etc.

For controller, I am less clear.

If you know an open source project or can share a lightweight example Todo App, it would help me understand your use cases and needs better.

Thanks, John Zabroski

On Thu, May 4, 2017, 12:39 PM Ian Johnson notifications@github.com wrote:

I like @seesharper https://github.com/seesharper idea, the only caveat to all this is that containers that actually have more features and compete in more benchmarks end up at a slight disadvantage compared to containers that don't compete in all. If we went this way maybe we could some how add extra registrations (and resolve them) for containers that don't compete in all so they don't get an advantage.

I spend most of my time these days in ASP.Net core web apps, to give an example roughly 30 types are resolved from the container before the first controller is even created. If you're doing custom controller and view activation the number of types being resolved can grow rather large for big applications.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/danielpalme/IocPerformance/issues/71#issuecomment-299241046, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbT_Si60WbzFl164iNP06FwPKHhk_Svks5r2f80gaJpZM4NQ5Lj .

[ipjohnson]

Hi John,

Close I was talking about the IViewPageActivator and IControllerActivator interfaces that are used by MVC to activate views and controllers.

A number of the DI containers provide their own implementations that can be plugged in (different MVC version wire up differently).

Feel free to email me if you have more questions for me so this issue can be closed out.

-Ian