From patchwork Mon Dec 22 11:39:17 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Earnshaw X-Patchwork-Id: 4395 Received: (qmail 20519 invoked by alias); 22 Dec 2014 11:39:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 20504 invoked by uid 89); 22 Dec 2014 11:39:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Message-ID: <549802E5.2010702@arm.com> Date: Mon, 22 Dec 2014 11:39:17 +0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "libc-alpha >> Glibc Development List" Subject: Improve generic stpcpy performance X-MC-Unique: 114122211392005601 I noticed while going through some benchmark results that the generic stpcpy was substantially slower than the simple_stpcpy in the benchmark itself. So, similar to Wilko's recent strcpy patch, this patch uses the same approach for stpcpy. Note that it does not help to use mempcpy, since that returns a value that points beyond the end of the copied data. OK? * string/stpcpy.c (__stpcpy): Rewrite using strlen and memcpy. diff --git a/string/stpcpy.c b/string/stpcpy.c index 9185acc..fd6eb1c 100644 --- a/string/stpcpy.c +++ b/string/stpcpy.c @@ -35,14 +35,8 @@ __stpcpy (dest, src) char *dest; const char *src; { - char *d = dest; - const char *s = src; - - do - *d++ = *s; - while (*s++ != '\0'); - - return d - 1; + size_t len = strlen (src); + return memcpy (dest, src, len + 1) + len; } #ifdef libc_hidden_def libc_hidden_def (__stpcpy)