Date: Mon, 01 Nov 1999 02:49:24 +0300 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: obrien@NUXI.com Cc: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, freebsd-arch@freebsd.org Subject: Re: stpcpy() Message-ID: <199910312349.CAA02684@tejblum.pp.ru> In-Reply-To: Your message of "Sun, 31 Oct 1999 14:50:49 PST." <19991031145049.A90745@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"David O'Brien" wrote:
> On Sun, Oct 31, 1999 at 02:07:26PM +1100, Bruce Evans wrote:
> > > Good stpcpy() could double performance in some cases. You would touch a
> > > symbol once where you previously touched it twice.
>
> > stpcpy() could halve performance in some cases (when the compiler inlines
> > and combines strcpy() and strlen() but doesn't do anything special with
> > stpcpy(), and inlining is good).
>
> Bruce hit the nail right on the head -- people are making assumptions
> with out know what their compiler is doing.
You omitted following Bruce's words:
> > In practice, gcc seems to only inline strlen().
At any rate, sptcpy() can be slower only if we are stupid enough or
the compiler is really ancient/braindamaged. If the compiler inlines
and combines strcpy() and strlen(), we can implement stpcpy() as
static __inline char *
stpcpy(char *__to, const char *__from)
{
return (strcpy(__to, __from) + strlen(__from));
}
in string.h and make the compiler perform all the optimizations.
>
> 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().
>
> > > It actually may matter in some text-processing applications.
>
> 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.
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.
The convenience is the main reason to add stpcpy() into libc. After the
"-v" option was added to mkdir, the antibloat arguments became utterly
nonsense.
Dima
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?199910312349.CAA02684>