Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Large amount of garbage with deep dependency tree #769

Closed
ReneZwanenburg opened this issue Jul 4, 2016 · 4 comments
Closed

Large amount of garbage with deep dependency tree #769

ReneZwanenburg opened this issue Jul 4, 2016 · 4 comments

Comments

@ReneZwanenburg
Copy link

Our ASP application has a few deeply nested dependency hierarchies, with the size of a tree in the order of thousands of objects. When resolving such a dependency, Autofac 3.5.2 generates a lot of garbage: loading a representative webpage results in ~ 50 MB worth of allocations coming from Autofac, less than one percent of the allocated bytes are for the resulting instances. The top allocations are ConcatIterators and various lambda's. It's not leaking, everything gets cleaned up nicely at the next GC cycle, but the high amount of allocations puts pressure on the GC and causes our heaps to be significantly larger than necessary.

There might be some improvements possible. I haven't looked at Autofac's code close enough to say for certain, but these kinds of changes often involve replacing linq and lambdas with something a bit less nice-looking around the heaviest allocating places. If you're potentially open to changes of this nature I'm willing to work on this.

@alexmg
Copy link
Member

alexmg commented Jul 10, 2016

We are definitely open to such improvements. I would work with the develop branch that has the current 4.0 RC version if you would like to look further into the issue.

@alexmg
Copy link
Member

alexmg commented Jan 17, 2017

I've pushed Autofac 4.3.0 to NuGet and look forward to taking this for a spin at the office tomorrow.

@nblumhardt
Copy link
Member

@ReneZwanenburg any chance you can try out the 4.3.0 build and let us know if it's improved matters? Cheers!

@tillig
Copy link
Member

tillig commented Aug 16, 2018

I'm going to close this with the caveat that if folks see specific ways to improve, we're totally open to that. PRs for optimizations [ideally without breaking API changes] are always welcome.

@tillig tillig closed this as completed Aug 16, 2018
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

4 participants