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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?
Дата
Msg-id 8510.1303835300@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Merlin Moncure <mmoncure@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: maximum digits for NUMERIC
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?