Closed ipjohnson closed 5 years ago
@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.
@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.
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.
@Barsonax , Hmm.. I have thought that it always one scope per controller.
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.
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
.
@jzabroski yes you could possible do that but I believe that's beyond the "scope" of this benchmark.
@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?
@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.
Does anyone have comments on this PR before @danielpalme merges it in?
@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
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.