updating asp.net core benchmark to have more scoped singletons

[ipjohnson]

This PR is to address concerns brought up in issue #115. I've made the test have 5 scoped singletons and changed the read:create ratio from 3:1 to 5:1 to make it more read heavy as specified in the issue.

[jzabroski]

@ipjohnson Something I've been thinking/wondering - wouldn't the benchmarks be better if there was a "Hugeness multiplier" so that people could pick a IoC container based on size of project? Like, I worked on a project with a lot of pseudo-cyclical references and so object graphs were routinely 30 objects deep. It's these types of benchmarks where we felt DryIoC shined.

[ipjohnson]

@jzabroski that could be interesting to people. That said this PR is specifically to address @barsonax concern that a particular container was “cheesing” the benchmark.

That said if you’d like to add a really large object to these I’m sure it would be welcome.

[Barsonax]

Nice job

I still think most of the time in the benchmark goes into creating the scoped instances and not actually resolving them.

What about using only 1 scope and resolve 3 controllers in that scope? I believe that should make for a nice 15:1 read write ratio while reducing the constant overhead of creating the scopes.

[dadhi]

@Barsonax , Hmm.. I have thought that it always one scope per controller.

[Barsonax]

Hmm you might be right here. Seems that in ASP .NET a new controller is created for every request. Since the scope here is the request scope there will only be 1 controller in a scope I believe.

This pretty much limits the amount of scoped instances any sane ASP .NET application will use/reuse.

Maybe a linkedlist might actually be a better datastructure for this particular workload due it being fast to add new instances and having less constant overhead.

[jzabroski]

1 Controller can have 1 or N scopes. The main use case for having multiple scopes within a single Controller is if the Controller Action is doing some massively parallel work, such as splaying data loading into N threads each with their own DbContext (since DbContext is not thread-safe).

Not all IoC frameworks elegantly support this pattern, or at all. It effectively requires the Func<T> design pattern to thread the ambient container context into the proxy for T.

[ipjohnson]

@jzabroski yes you could possible do that but I believe that's beyond the "scope" of this benchmark.

[jzabroski]

@jzabroski yes you could possible do that but I believe that's beyond the "scope" of this benchmark.

This particular benchmark, yes. Should there be a separate benchmark?

[ipjohnson]

@jzabroski good question maybe best posed in a new issue so all stake holders can express their interest. I think you could probably come up with 100+ benchmarks that are interesting to some segment of DI users that aren't covered here.

[ipjohnson]

Does anyone have comments on this PR before @danielpalme merges it in?

[jzabroski]

@jzabroski good question maybe best posed in a new issue so all stake holders can express their interest. I think you could probably come up with 100+ benchmarks that are interesting to some segment of DI users that aren't covered here.

Created #118