You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we have basic trimming support in place, where unused arrays will be removed from the pool in response to memory pressure, we should re-evaluate these constraints. For example, that number of buckets limits the size of arrays that can be pooled, which means if you call ArrayPool<byte>.Shared.Rent(10_000_000), it's just going to allocate a new array, always, and returning that array to the pool will just drop it. Should we increase the number of buckets such that all array sizes can be cached? Should we increase the number of arrays per size that can be cached? Etc.
@stephentoub do you have evidence to suggest this ought to get attention for 3.0? Or is just more of a general observation that there may be opportunities here. My inclination would be to leave these values the same for 3.0 without evidence they're causing a problem.
@stephentoub I'm pushing this to future for now given that it has been logged for a year now, but feel free to pull back to 5.0 if this is something we want to fix there.
Activity
ahsonkhan commentedon Jun 20, 2019
Generally, ArrayPool related issues are tagged with
area-System.Buffers(within corefx), but we don't have such granular labels here.https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3Aarea-System.Buffers
What would be an appropriate area label for this?
RussKeldorph commentedon Jun 21, 2019
@danmosemsft Could you triage?
danmoseley commentedon Jun 21, 2019
@stephentoub do you have evidence to suggest this ought to get attention for 3.0? Or is just more of a general observation that there may be opportunities here. My inclination would be to leave these values the same for 3.0 without evidence they're causing a problem.
stephentoub commentedon Jun 21, 2019
No, this should be post-3.0.
danmoseley commentedon Jun 21, 2019
Thanks. BTW feel free to set milestone as needed
joperezr commentedon Jul 7, 2020
@stephentoub I'm pushing this to future for now given that it has been logged for a year now, but feel free to pull back to 5.0 if this is something we want to fix there.
stephentoub commentedon Jul 7, 2020
That's fine, thanks.