Re: Faster StrNCpy - Mailing list pgsql-hackers

I did a couple more tests using x86 architectures.  On a rather old
Pentium-4 machine running Fedora 5 (gcc 4.1.1, glibc-2.4-11):

$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to be very slow."' -DN="(1024*1024)" -o x
x.cy.c strlcpy.c  
 
NONE:        786305 us
MEMCPY:     9887843 us
STRNCPY:   15045780 us
STRLCPY:   17555563 us
U_STRLCPY: 14994639 us
LENCPY:    19700346 us

$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to be very slow."' -DN=1 -o x x.c y.c
strlcpy.c
 
NONE:        562001 us
MEMCPY:     2026546 us
STRNCPY:   11149134 us
STRLCPY:   13747827 us
U_STRLCPY: 12467527 us
LENCPY:    17672899 us

(STRLCPY is our CVS HEAD code, U_STRLCPY is the unrolled version)

On a Mac Mini (Intel Core Duo, OS X 10.4.8, gcc 4.0.1), the system has a
version of strlcpy, but it seems to suck :-(

$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to be very slow."' -DN="(1024*1024)" -o x
x.cy.c strlcpy.c ; ./x
 
NONE:        480298 us
MEMCPY:     7857291 us
STRNCPY:   10485948 us
STRLCPY:   16745154 us
U_STRLCPY: 18337286 us
S_STRLCPY: 20920213 us
LENCPY:    22878114 us

$ gcc -O3 -std=c99 -DSTRING='"This is a very long sentence that is expected to be very slow."' -DN=1 -o x x.c y.c
strlcpy.c; ./x
 
NONE:        480269 us
MEMCPY:     1858974 us
STRNCPY:    5405618 us
STRLCPY:   16364452 us
U_STRLCPY: 16439753 us
S_STRLCPY: 19134538 us
LENCPY:    22873141 us

It's interesting that the unrolled version is actually slower here.
I didn't dig into the assembly code, but maybe Apple's compiler isn't
doing a very good job with it?

Anyway, these results make me less excited about the unrolled version.

In any case, I don't think we should put too much emphasis on the
long-source-string case.  In essentially all cases, the true source
string length will be much shorter than the target buffer (were this
not so, we'd probably be needing to make the buffer bigger), and strlcpy
will certainly beat out strncpy in those situations.  The memcpy numbers
look attractive, but they ignore the problem that in practice we usually
don't know the source string length in advance --- so I don't think
those represent something achievable.

One thing that seems real clear is that the LENCPY method loses across
the board, which surprised me, but it's hard to argue with numbers.

I'm still interested to experiment with MemSet-then-strlcpy for namestrcpy,
but given the LENCPY results this may be a loser too.
        regards, tom lane