
 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.
      
  
 


Tue, 23 Jan 2001 00:22:11 +0100 (CET)
Karel Zak <zakkr@zf.jcu.cz>
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

Mon, 22 Jan 2001 20:06:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
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


Tue, 23 Jan 2001 16:59:50 +0100 (CET)
Karel Zak <zakkr@zf.jcu.cz>
Re: realloc suggestion 