From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: MemSet inline for newNode |
Date: | 2002-11-11 02:50:03 |
Message-ID: | 23217.1036983003@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I thought someone had tested that there was little/no performance
> difference between these two statements:
> MemSet(ptr, 0, 256)
> vs.
> i = 256;
> MemSet(ptr, 0, i)
But with any reasonably smart compiler, those *will* be the same because
the compiler can do constant-folding (ie, it knows i is 256 when control
reaches the MemSet). Pushing the MemSet into MemoryContextAlloc
eliminates the possibility of knowing the size argument's value.
> I can back out my changes, but it would be easier to see if there is a
> benefit before doing that. Personally, I am going to be surprised if a
> single conditional tests in MemSet (which is not in the assignment loop)
> will make any measurable difference.
Then why were we bothering? IIRC, this was being sold as a performance
improvement.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-11-11 02:58:07 | Re: MemSet inline for newNode |
Previous Message | Bruce Momjian | 2002-11-10 23:07:34 | Re: [PATCHES] MemSet inline for newNode |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-11-11 02:58:07 | Re: MemSet inline for newNode |
Previous Message | Neil Conway | 2002-11-10 23:09:09 | more SGML fixes |