Re: tweaking MemSet() performance

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Sullivan <andrew(at)libertyrms(dot)info>, Neil Conway <neilc(at)samurai(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tweaking MemSet() performance
Date: 2002-08-30 14:53:19
Message-ID: 200208301453.g7UErJv00664@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Would you please retest this. I have attached my email showing a
> > simpler test that is less error-prone.
>
> What did you consider less error-prone, exactly?
>
> Neil's original test considered the case where both the value being
> set and the buffer length (second and third args of MemSet) are
> compile-time constants. Your test used a compile-time-constant second
> arg and a variable third arg. It's obvious from looking at the source
> of MemSet that this will make a difference in what an optimizing
> compiler can do.

It was less error-prone because you don't have to recompile for every
constant, though your idea that a non-constant length may effect the
optimizer is possible, though I assumed for >=64, the length would not
be significant to the optimizer.

Should we take it to 1024 as a switchover point? I am low at 512, and
others are higher, so 1024 seems like a good average.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2002-08-30 15:04:52 Re: Accessing original TupleDesc from SRF
Previous Message Joe Conway 2002-08-30 14:46:10 Re: Accessing original TupleDesc from SRF