Thread: realloc suggestion

realloc suggestion

From
Karel Zak
Date:
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
probablybetter use   current brutal forge solution.      
 



Re: realloc suggestion

From
Tom Lane
Date:
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


Re: realloc suggestion

From
Karel Zak
Date:
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