| (author) > A very well thought out set of functionality Thanks! It's only an experiment at this stage but I was pleasantly surprised it worked in such a small size. > slices (...) generally faster It works wonders. The upcoming bft_split function is gonna be dead fast. I optimize things by adopting the laziest possible personna : do I really need to copy this ? No. What if the user wants to append stuff to a split part ? We'll see then. > Allocating only blocks sized by a power of two is potentially memory wasting It just follows the classical doubling of requested size. In high exponents though I admit it'll be wasteful. > some clever base between 1 and 2 I wouldn't have thought of it, nor known how to. Would it be somehow costly ? Shifting is basically free. > support 'mmap' Interesting. But shouldn't we keep the lib surface minimal and just leave this to the user ? She maps then takes a view on it ? |
It's 3. ISO 3, preferred numbers: https://en.wikipedia.org/wiki/Preferred_number#Computer_engi...
For your application, I would apply a heuristic which includes the x3 values at some point (256KiB?), and maybe the x5 values near/at 256MiB.
Allocation is so expensive relative to calculating the allocated value that you could use something really complex and it would work. Certainly multiplying by a factor between one and two and rounding to the nearest word would work, there's no way you'd see a performance difference from the calculation.
The advantage of ISO 3 is that the user always gets a familiar number of allocated bytes back.