realloc suggestion

Started by Karel Zakalmost 25 years ago3 messages
#1Karel Zak
zakkr@zf.jcu.cz

Hi Tom,

I again a little look at aset code and I probably found small performance
reserve in small chunks (chunk <= ALLOC_CHUNK_LIMIT) reallocation.

Current code for *all* small chunks call AllocSetAlloc() for new larger
chunk, memcpy() for data copy, AllocSetFree() for old chunk. But this
expensive solution is not needful for all chunks in all instances.

Sometimes is AllocSetRealloc() called for chunk that is *last* chunk
in actual block and after this chunk is free space (block->freeptr). If
after this reallocated chunk is sufficient memory not is needful create
new chunk and copy data, but is possible only increase chunk->size and move
set->block->freeptr to new position.

Current code always create new chunk and old add to freelist. If you
will call often prealloc (with proper size) over new context block this
block will spit to free not used chunks and only last chulk will used.

I test this idea via folloving code taht I add to AllocSetRealloc() to
"Normal small-chunk case".

fprintf(stderr, "REALLOC-SMALL-CHUNK\n");

{
char *chunk_end = (char *) chunk +
chunk->size + ALLOC_CHUNKHDRSZ;

if (chunk_end == set->blocks->freeptr)
{
/*
* Cool, prealloc is called for last chunk
* in actual block, try check space after this
* chunk.
*/
int sz = set->blocks->endptr -
set->blocks->freeptr;

fprintf(stderr, "REALLOC-LAST-CHUNK\n");

if (sz + chunk->size >= size)
/*
* After chunk is sufficient memory
*/
fprintf(stderr, "NEED-EXPAND-CHUNK-ONLY\n");
}
}

For example if I run regress test I found "NEED-EXPAND-CHUNK-ONLY"
in 38% of all AllocSetRealloc() usage! - in my other tests with own
DB dumps it was less (10%). It's more often than I was expect :-)

My suggestion is expand chunk if after chunk is in block free space
and not by brutal forge create always new chunks and call expensive
AllocSetAlloc(), AllocSetFree() and memcpy().

Comments?

Karel

PS. anyway .. needful is check if new (wanted) size is not large than
ALLOC_CHUNK_LIMIT too. In this situation will probably better use
current brutal forge solution.

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Karel Zak (#1)
Re: realloc suggestion

Karel Zak <zakkr@zf.jcu.cz> writes:

I again a little look at aset code and I probably found small performance
reserve in small chunks (chunk <= ALLOC_CHUNK_LIMIT) reallocation.

Hmm. I wouldn't have thought that realloc got called often enough to be
worth optimizing, but it does seem to get called a few hundred times
during the regress tests, so maybe it's worth a little more code to do
this. (Looks like most of the realloc calls come from enlargeStringInfo
while dealing with long query strings --- since in this case the string
buffer is the only thing yet allocated in QueryContext, the special-case
check wins.)

I've committed this change. Thanks for the suggestion!

regards, tom lane

#3Karel Zak
zakkr@zf.jcu.cz
In reply to: Tom Lane (#2)
Re: realloc suggestion

On Mon, 22 Jan 2001, Tom Lane wrote:

Karel Zak <zakkr@zf.jcu.cz> writes:

I again a little look at aset code and I probably found small performance
reserve in small chunks (chunk <= ALLOC_CHUNK_LIMIT) reallocation.

Hmm. I wouldn't have thought that realloc got called often enough to be
worth optimizing, but it does seem to get called a few hundred times
during the regress tests, so maybe it's worth a little more code to do
this. (Looks like most of the realloc calls come from enlargeStringInfo
while dealing with long query strings --- since in this case the string
buffer is the only thing yet allocated in QueryContext, the special-case
check wins.)

I've committed this change. Thanks for the suggestion!

I love OpenSource and CVS source distribution model - only couple hours
between idea and official source change :-)

Karel