Re: Problem in Strdup()

On Tue, 30 Aug 2005 04:59:07 +0000, Walter Roberson wrote:

> In article <pan.2005.08.30.04.12.42.949291@xxxxxxx>, Mac <foo@xxxxxxx> wrote:
>>On Mon, 29 Aug 2005 19:52:17 +0000, Keith Thompson wrote:
>
>>> strcpy() scans until it sees a '\0'. memcpy() scans for a specified
>>> number of bytes. It's not at all obvious that one is going to be
>>> faster than the other (though one or the other could well be on some
>>> particular platform).
>
>>Well, it is VERY hard for me to imagine that strcpy() will execute faster
>>than memcpy() when the string length is known ahead of time. I think in
>>general, memcpy() will be as fast as the implementers know how to make it.
>
> A memcpy() implementation could potentially detect the case where
> both memory areas had the same word alignment, copy a few bytes to
> reach the aligning point, and then copy words (or longwords) until
> it reached near the end and then copied bytes again. This would,
> for example, work if both areas happened to be the beginning of
> malloc()'d memory, as malloc() uses the most restrictive alignment.
> It could do similarily for the case where the areas could be aligned
> with shorter words... even moving by short int might be faster than
> moving by byte.
>
> Unfortunately, in a lot of cases, the two areas will not share any
> mutual alignment, such as if one is copying starting at an "odd" memory
> location and the source starts at an "even" location. And in that
> particular case, strcpy() is potentially faster. When the byte
> is moved, many architectures will automatically "test" the byte
> value, allowing a "branch on zero" without the overhead of an
> explicit test. That can be faster than decrementing a counter
> location (which requires a write operation, even if only a
> register write) and branching on the implicitly-tested value of it --
> it takes one less operation, since one has moved the byte anyhow...

I'm not going to enter into this kind of argument here. Anyone who cares
which way is faster should profile both ways. Enough said.

;-)

--Mac

.

Relevant Pages

  • Re: Problem in Strdup()
    ... it is VERY hard for me to imagine that strcpy() will execute faster ... >than memcpy() when the string length is known ahead of time. ... malloc'd memory, as mallocuses the most restrictive alignment. ...
    (comp.lang.c)
  • Re: Does an array of char have alignment issues?
    ... gcc's memcpy with e.g. -O2 would certainly fail since the memcpy macro ... copies memory region as series of 32bit integers. ... you switch on the alignment of the source and target ... Even on fast CPUs with merging writebuffers it is better to do ...
    (comp.sys.arm)
  • Re: question for C experts - strcpy vs memcpy
    ... strcpy will copy until a x'00 is encountered. ... copy all of storage until it tries to access un-owned storage, ... Memcpy will copy storage for the length indicated. ... Search the archives at http://bama.ua.edu/archives/ibm-main.html ...
    (bit.listserv.ibm-main)
  • Re: question for C experts - strcpy vs memcpy
    ... If you know the length of the field to be copied, the memcpy is ... Memcpy generates an MVC instruction in the compilation, ... strcpy generates a call to a routine that does the strcpy. ... reader of this message is not the intended recipient or an agent ...
    (bit.listserv.ibm-main)
  • Re: strtok and strtok_r
    ... which was using strcpy() at the time. ... memcpy() vs strcpyperformance. ... measure L1 cache performance only. ... Run program with Option A. Reboot machine. ...
    (comp.lang.c)