Date: 01 Nov 1999 01:24:10 +0000 From: Randell Jesup <rjesup@wgate.com> To: freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <ybuu2n7gg1x.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Dmitrij Tejblum's message of "Mon, 01 Nov 1999 02:49:24 %2B0300" References: <199910312349.CAA02684@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Dmitrij Tejblum <tejblum@arc.hq.cti.ru> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybuu2n7gg1x.fsf>