Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c?

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

/** "Compact" palloc: allocate without extra palloc overhead.** Since we have no need to free the ispell data items
individually,there's* not much value in the per-chunk overhead normally consumed by palloc.* Getting rid of it is
helpfulsince ispell can allocate a lot of small nodes.** We currently pre-zero all data allocated this way, even though
someof it* doesn't need that.  The cpalloc and cpalloc0 macros are just documentation* to indicate which allocations
actuallyrequire zeroing.*/
 
#define COMPACT_ALLOC_CHUNK 8192        /* must be > aset.c's allocChunkLimit */
#define COMPACT_MAX_REQ         1024    /* must be < COMPACT_ALLOC_CHUNK */

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?

merlin


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

Предыдущее
От: Sim Zacks
Дата:
Сообщение: Re: Proposal - asynchronous functions
Следующее
От: David Fetter
Дата:
Сообщение: Re: Proposal - asynchronous functions