bitfield behaving in weird way

[arpit728]

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?

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