Re: Faster StrNCpy - Mailing list pgsql-hackers

This is from October 2006.  Is there a TODO here?

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
> 
>                http://archives.postgresql.org

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +