From owner-freebsd-arch Sun Oct 31 21:28:25 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id C634C1526D for ; Sun, 31 Oct 1999 21:27:57 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA03470 for ; Mon, 1 Nov 1999 06:27:56 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA70928 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 06:27:55 +0100 (MET) Received: from mail.tvol.com (mail.wgate.com [38.219.83.4]) by hub.freebsd.org (Postfix) with ESMTP id A280814BC4 for ; Sun, 31 Oct 1999 21:27:43 -0800 (PST) (envelope-from rjesup@wgate.com) Received: from jesup.eng.tvol.net (jesup.eng.tvol.net [10.32.2.26]) by mail.tvol.com (8.8.8/8.8.3) with ESMTP id AAA04954 for ; Mon, 1 Nov 1999 00:22:59 -0500 (EST) Reply-To: Randell Jesup To: freebsd-arch@freebsd.org Subject: Re: stpcpy() References: <199910312349.CAA02684@tejblum.pp.ru> From: Randell Jesup Date: 01 Nov 1999 01:24:10 +0000 In-Reply-To: Dmitrij Tejblum's message of "Mon, 01 Nov 1999 02:49:24 +0300" Message-ID: X-Mailer: Gnus v5.6.43/Emacs 20.4 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dmitrij Tejblum writes: >At any rate, stpcpy() can be slower only if we are stupid enough or >the compiler is really ancient/braindamaged. >> Also, strcpy() and strlen() could easily be highly optimized ASM routines >> that together are still faster than a C stpcpy(). > >There is nothing that prevent to clone the highly optimized ASM strcpy() >to create a highly optimized ASM stpcpy(). Quite true - in fact, stpcpy() is almost guaranteed to be as fast as strcpy, perhaps even faster if keeping the original pointer around causes a memory access and/or use of an extra register. (Minimal difference, of course - the real point is that it isn't slower, and it's trivial to implement as a modification of strcpy().) >> Yes, BUT one should only use these non-standard functions AFTER they've >> actually done some profiling and see where the program is REALLY spending >> their time. Sure, but why not code for efficiency to start with? Especially in such an obvious case. I'll bet 95% of programmers working on systems where stpcpy has been part of the libraries for a long time don't even know that it isn't standard. I don't know about you, but I code for systems where cutting CPU usage by 1% can actually make a real difference in the field and to costs. Perhaps this won't get me 1% - but a fraction of a percent here and another there adds up, and this is at truely zero cost. Other people will have applications where this might by more. >Really? Why? My colleagues use Windows and occasionally use stpcpy(), >just because it is CONVENIENT and obviously cannot make their program >slower. If the program is slower on FreeBSD (or even not compile), this is >not their fault. While non-ANSI standard, this particular function has been virtually standard in PC compilers for a Long Time. Like I said, near the start of this, probably for more than a decade it's been in every DOS/Win/Amiga/OS2/etc compiler I've used (unless my memory fails me, which it might). Why is there such vitriol being pointed at people who use a function that's been in every compiler they've ever had access to, can't hurt performance, could improve performance of heavily string-oriented apps, and is small? Quite honestly, I'd assumed that stpcpy() was in the library already. If I want strict ANSI, I'll tell the compiler that. I can't remember the last time I did that - I think it was when I was beta-testing commercial compilers 6 or 7 years ago. As for the bloat argument: Bloat in libraries is very different than bloat in executables; the impact is MUCH smaller. And as 'bloat' goes, this is about the most trivial example one could come up with. IMHO. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94) rjesup@wgate.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message