Run following commands to reproduce.
Case-1: Normal
bitfield abc set u32 #22 1
memory usage abc -->>141
Case-2: weird
bitfield abc set u32 #0 1
memory usage abc -->> 51
bitfield abc set u32 #22 1
memory usage abc -->>233
First I executed bitfield command as mentioned in case 1 and I got 141 bytes as memory usage.
Then I run two commands as mentioned in case-2 and I got 233 bytes as memory usage.
I think memory usage should come as 141 in case 2 as well.
Why does memory usage is more in case 2, is it a bug or I am missing something?
Comment From: oranagra
Thanks for the report.
The difference arises from the greedy allocation mechanism of our sdsMakeRoomFor. When trying to increase an allocation to be bigger, it allocates a little bit more to be prepared that more data will be added later. So if you'll be incrementally adding one bit at a time to the key, it'll be faster with this mechanism (not having to realloc often). as you've seen, you can avoid it by allocating the right size from the get-go (setting the last bit first). p.s. this greedy mechanism can take up to twice the needed memory, and at most 1MB spare.
@yossigo, considering that sds now takes responsibility of it's internal fragmentation, maybe this greedy mechanism in sdsMakeRoomFor isn't needed in this case, and BITFIELD or sdsgrowzero can be changed to non-greedy? i.e. in any case it'll have some excess.