-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DI allocations improvements #47607
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @eerhardt, @maryamariyan Issue DetailsIn Orchard CMS which is quite allocaty, the second culprit is DI. This code path does a database request and renders the html. During that process several services are resolved, increasing the size of the scoped service dictionary. Stack trace of allocations:
And overall memory consumption:
This issue is just to raise some concern, and maybe there is nothing better to be done.
|
The thing that stands out to me is the dictionary resize. We could potentially improve this by specifying a capacity like max(scoped/2, 30) something like this (I picked those numbers out of thin air) |
@sebastienros - are there instructions on how to run this locally to investigate? |
Here is how I do it:
I can help more if you need. I can also provide this scenario as a |
I was discussing this with @maryamariyan and one thing we might want to try is re-using the scoped dictionary. This makes some assumption that scopes look the same and we have no idea to identify similar scopes (say by an id) so we can try it out with a small pool (say number of size of number of cores). This won't help for long running scopes in things like Blazor server, or Orleans but will do 2 things:
We might also want to keep the dictionaries to a reasonable size so we don't bloat memory (maybe calling TrimExcess if we reached some number of entries threshold). |
Re-opening this as I reverted the change. I've added an event to the event source so we can figure out just how heterogeneous or homogenous scopes are within the same container. |
Moving to 7.0 since this isn't a "must have" for 6.0. |
In Orchard CMS which is quite allocaty, the second culprit is DI. This code path does a database request and renders the html. During that process several services are resolved, increasing the size of the scoped service dictionary.
Stack trace of allocations:
And overall memory consumption:
This issue is just to raise some concern, and maybe there is nothing better to be done.
The text was updated successfully, but these errors were encountered: