inline newNode()
Bruce Momjian
> Neil Conway wrote:
> > BTW, regarding the newNode() stuff: so is it agreed that Bruce's patch
> > is a performance win without too high of a code bloat / uglification
> > penalty? If so, is it 7.3 or 7.4 material?
>
> Not sure. It is a small patch but we normally don't do performance
> fixes during beta unless they are major.
This performance improvement isn't related to a specific user problem
report, so I am going to hold it for 7.4. At that time we can also
research whether palloc0 should be used in other cases, like palloc
followed by MemSet.
The only issue there is that palloc0 can't optimize away constants used
in the macro so it may be better _not_ to make that change. Neil, do
you have any performance numbers comparing MemSet with constant vs.
variable parameters, e.g:
MemSet(ptr, 0, 256)
vs.
i = 256;
MemSet(ptr, 0, i)
--
Bruce Momjian | http://candle.pha.pa.us
pg...@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org
Bruce Momjian
> Neil Conway writes:
>
> > MemSet(): ~9.6
> > memset(): ~19.5
> > __builtin_memset(): ~10.00
>
> I did my own tests with this code and the results vary wildly between
> platforms. (I do not list __builtin_memset() because the results were
> invariably equal to memset().)
>
> Platform buffer memset() MemSet()
>
> freebsd 32 5.3 4.9
> freebsd 256 23.3 24.2
> mingw 32 0.5 2.0
> mingw 256 6.6 10.5
> unixware 256 15.2 10.3
> unixware 1024 29.2 34.1
> cygwin 256 6.7 15.8
>
> "freebsd" is i386-unknown-freebsd4.7 with GCC 2.95.4.
> "mingw" is i686-pc-mingw32 with GCC 3.2.
> "unixware" is i586-sco-sysv5uw7.1.3 with vendor compiler version 4.1.
> "cygwin" is i686-pc-cygwin with GCC 2.95.3.
>
> GCC was run as 'gcc -O2 -Wall'. (I also tried 'gcc -O3 -finline' but
> that gave only minimally better results.) The SCO compiler was run as
> 'cc -O -Kinine -v'.
>
> Make of those results what you will, but the current cross-over point of
> 1024 seems very wrong.
No question 1024 looks wrong on a lot of platforms. On Sparc, we were
seeing a crossover even higher, and on many like BSD/OS, the crossover
is much lower. Without some platform-specific test, I don't know how we
are going to set this correctly. Should we develop such a test? Do we
have enough MemSet usage in the 256-4k range that people would see a
difference between different MEMSET_LOOP_LIMIT values?