Skip to content

Re-evaluate defaults in ArrayPool.Shared #12800

Closed as not planned
Closed as not planned

Description

@stephentoub

Prior to trimming support being added in, ArrayPool.Shared was given several hardcoded upperbounds, e.g.
https://github.com/dotnet/coreclr/blob/6631a7a0f9b6268f5e6c0f609a2d0d2a730a2118/src/System.Private.CoreLib/shared/System/Buffers/TlsOverPerCoreLockedStacksArrayPool.cs#L33-L38

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.

cc: @JeremyKuhne, @jkotas

Activity

  1. ahsonkhan commented on Jun 20, 2019

    @ahsonkhan
    Contributor

    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?

  2. RussKeldorph commented on Jun 21, 2019

    @RussKeldorph
    Contributor

    @danmosemsft Could you triage?

  3. danmoseley commented on Jun 21, 2019

    @danmoseley
    Contributor

    @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.

  4. stephentoub commented on Jun 21, 2019

    @stephentoub
    MemberAuthor

    No, this should be post-3.0.

  5. danmoseley commented on Jun 21, 2019

    @danmoseley
    Contributor

    Thanks. BTW feel free to set milestone as needed

  6. transferred this issue fromdotnet/coreclron Jan 31, 2020
  7. added this to the 5.0 milestone on Jan 31, 2020
  8. added
    enhancementProduct code improvement that does NOT require public API changes/additions
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Jul 7, 2020
  9. joperezr commented on Jul 7, 2020

    @joperezr
    Member

    @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.

  10. modified the milestones: 5.0.0, Future on Jul 7, 2020
  11. stephentoub commented on Jul 7, 2020

    @stephentoub
    MemberAuthor

    That's fine, thanks.

  12. ghost locked as resolved and limited conversation to collaborators on Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area-System.RuntimeenhancementProduct code improvement that does NOT require public API changes/additionstenet-performancePerformance related issue

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions