On Tue, Sep 23, 2014 at 12:49:56PM +0100, Dave Mitchell wrote: > It occurred to me that malloc() libraries are likely to have some > reasonably sane and predictable behaviour (ha ha, I know, I know...). > For example, since malloc() guarantees alignment for any kind of variable, > its likely to allocate blocks of at least 4/8 bytes on 32/64-bit systems; > it's therefore probably not efficient to malloc PVX's of less than 4/8 > bytes (we'll just waste time later calling realloc() which just returns > the same address). > > Similarly, the malloc may in fact over-allocate, and in fact some quick > tests with the malloc on my 64-bit linux system implies that it initially > allocates 24 bytes, even for a malloc(1). ... > which implies the malloc() library initially allocates 24 bytes, then > reallocs in 16 byte increments. A simple probe like the above at startup > time might reveal the optimum size to initially size strings, and what > factor to round up by when reallocing. Allocations should be at least 16 byte aligned on amd64/x86_64 systems, some instructions, including some gcc/clang can generate, require 16-byte alignment. TonyThread Previous | Thread Next