Fix high water mark coalescing in memory pools #908
Conversation
…oalesced pool size The non-actual high water mark does not include the overallocated size when rounding user allocations up to the alignment. This means that the non-actual high water mark may be too small when repeatedly allocating and deallocating the same sizes in a pool, leading to unnecessary reallocation of the backing buffers.
|
Thinking about this a bit more, this isn't quite right either. There's a missing counter, which is the high water mark of "current bytes". In QuickPool, |
I had started looking at this, and I think that's the right approach. Let me know if you would like to tackle this. Thanks! |
Good to hear, thanks! If you already have something started and you have specific thoughts on how to do it, by all means go for it. You do know the codebase better than I do after all! I'm happy to continue in this direction if it helps though, I probably just need a bit more time and support, so if you're happy to wait for me to get this into a good state I'll keep at it. |
|
@davidbeckingsale I've pushed some updates hopefully in the direction that you had in mind. One open question is if the non- |
Looks good. I think the non-hwm can stick with actualSize since that is already including the alignment. (actual size is the actual amount of bytes allocated by the pool). |
|
Merged in #917 |
Fixes #906.
This adds two methods,
getAlignedSizeandgetAlignedHighwaterMarktoQuickPoolandDynamicPoolList. Them_current_bytes/m_current_sizemembers have been renamedm_aligned_bytes.getAlignedHighwaterMarkis now used instead ofgetHighWatermarkin thehwmcoalescing heuristics.