Re: Faster StrNCpy

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +