Re: [PATCH 2/2] strbuf: allow to use preallocated memory

From: William Duclot <william.duclot@ensimag.grenoble-inp.fr>
Date: May 30, 2016, 22:46 UTC
Message-ID: <1686469496.216457.1464648383516.JavaMail.zimbra@ensimag.grenoble-inp.fr>
In-Reply-To: <20160530215652.GA6456@glandium.org>

Mike Hommey <mh@glandium.org> writes:

Show 17 quoted lines

>>  struct strbuf {
>> +	unsigned int flags;
>>  	size_t alloc;
>>  	size_t len;
>>  	char *buf;
>>  };
> 
> Depending whether the size of strbuf matters, it /might/ be worth
> considering some packing here. malloc() usually returns buffers that can
> contain more data than what is requested. Which means allocation sizes
> could be rounded and that wouldn't change the amount of allocated
> memory. On glibc malloc_usable_size(malloc(1)) apparently returns 24.
> On jemalloc, it's 4 or 8. It's in the same ballbark with many
> allocators.
> 
> So, it would be possible to round alloc such that it's always a multiple
> of, say, 4, and stick flags in the low, unused bits.

If I'm not mistaken, the memory allocated is not necessarily linear with the size asked, depending on the algorithm used by the allocator and/or the kernel. The system for exemple use powers of two, if the user asks for exactly 2^x bytes, adding the space for the flags would lead to an allocation of 2^(x+1) bytes. Way worse than storing an unsigned. If the allocator use a fibonnaci system, we can't even rely on multiples of 4 (or 2). I'm not sure the fibonnaci system is actually used by any allocator, but my point is that I'm not sure it is a good thing to rely on such low-level implementations.

> Whether it's worth doing is another question.

I'd say it is not, we generally lack time more than space, storing an unsigned seems very reasonable compared to operations involved in using malloc() leftovers :) Not even talking about growing buffers, so realloc(), so a whole new set of problems...