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.c y.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.c y.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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
