Marc Colosimo <mcolosimo@mitre.org> writes:
> I'm using 7.4.5 on Mac OS X (G5) and was profiling it to see why it is
> SO SLOW at committing inserts and deletes into a large database. One
> of the many slowdowns was from MemSet. I found an old (2002) thread
> about this and retried the tests (see below). The main point is that
> the system memset crushes pg's!!
Hmm. I tried to duplicate this on my G4 laptop, and found that they
were more or less on a par for small-to-middling block sizes (using
"gcc -O2"). Darwin's memset code must have some additional tweaks for
use on G5 hardware. Good for Apple --- this is the sort of thing that
OS vendors *ought* to be doing. The fact that we can beat the system
memset on so many platforms is an indictment of those platforms.
> Is it possible to add a define to call
> the system memset at build time! This probably isn't the case on other
> systems.
Feel free to hack the definition of MemSet in src/include/c.h. See the
comments for it for more context.
Note that for small compile-time-constant block sizes (a case your test
program doesn't test, but it's common in pgsql), gcc with a sufficiently
high optimization setting can unroll the loop into a linear sequence of
words zeroings. I would expect that to beat the system memset up to a
few dozen words, no matter how tense the memset coding is. So you
probably want to think in terms of reducing MEMSET_LOOP_LIMIT rather
than diking out the macro code altogether. Or maybe reduce MemSet to
"memset(...)" but leave MemSetAligned and/or MemSetTest/MemSetLoop
as-is. In any case, reporting results without mentioning the compiler
and optimization level in use isn't going to convince anybody ...
regards, tom lane