Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> I was poking around in the allocator code out of curiosity after
> reading the thread 'Improving the memory allocator', and noticed the
> following in spell.c:

> #define COMPACT_ALLOC_CHUNK 8192 /* must be > aset.c's allocChunkLimit */

> In aset.c, we have,

> #define ALLOC_MINBITS 3 /* smallest chunk size is 8 bytes */
> #define ALLOCSET_NUM_FREELISTS 11
> #define ALLOC_CHUNK_LIMIT (1 << (ALLOCSET_NUM_FREELISTS-1+ALLOC_MINBITS))

> 1 << 13 gives 8192 if my math is correct.

> Note the comment, 'must be > aset.c's allocChunkLimit'. Is the
> comment wrong or the assumption wrong?

Hmm ... the idea behind that comment is evidently that it's best if the
blocks allocated by this code form independent malloc blocks in aset.c;
but right offhand I can't see why that'd be important. It's obviously
not functionally necessary, since the code works as-is, and I don't
immediately see a reason to think that it'd be more efficient. If
anything it might be best the way it is, with the allocation
corresponding to the largest allowable small-chunk size.

I'm thinking the comment is just brain fade ... which is annoying
because I have a feeling it's my own comment :-( ... but I'm darned
if I can reconstruct the reasoning for it now.

regards, tom lane