🥑 Request For Feedback: gpu-allocator CPU side memory consumption #260
Description
⛰️ Background
Over the years we've gotten quite a few PRs to reduce the memory consumption in gpu-allocator on the CPU side and we are trying to understand why we're getting these PRs since for most use-cases we have in mind the CPU side overhead of gpu-allocator for us has been a non-issue and sometimes these PRs introduce some kind of maintenance or API burden in terms of more complex or less straightforward code.
🙋 Question to the community
What we're trying to figure out then, is why these PRs come up and what kind of use-cases folks are having where they have a need to address this general overhead. Because I'm trying to understand if this is a side-effect of gpu-allocator being a memory allocation library (and will thus attract memory focussed developers), or if there are some use-cases which we just don't see, where this is inherently a problem.
Can folks that have filed these kinds of PRs, or are planning to file some of these PRs do us 2 small favors that will make it significantly easier for us to accept these kinds of changes:
- In the PR description please provide concrete measurements of the overhead from a memory profiling tool
- In the PR description also provide their use-case of
gpu-allocator, ideally in a way that we can understand the allocation patterns behind it - In this issue weigh in on the relevance and need for these reductions.
🔮 Going forward
We love serving this community and we think gpu-allocator is a valuable addition to the Rust community in general so we want to serve folks right, however we also have to balance maintenance cost of the library itself. Solving memory allocation is a difficult enough problem, solving it with memory constrained data structures is even harder and so some of these PRs require a careful trade-off, and understanding use-cases of gpu-allocator will only help understand if some of these trade-offs are worth it.