Date: Wed, 18 Oct 1995 15:26:50 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, davidg@Root.COM Cc: CVS-commiters@freefall.freebsd.org, cvs-lib@freefall.freebsd.org Subject: Re: cvs commit: src/lib/libc/stdlib getenv.c Message-ID: <199510180526.PAA12213@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>The __findenv() wart is now duplicated. It is inlined in getenv() and
> I'm aware of that and it was quite intentional. getenv() is called often,
>setenv() is rarely called. There is no reason to inline __findenv() for
>setenv() and unsetenv(), and inlining it for all three cases would just
>create yet one more copy. It was cheap to inline it for getenv() since it
I messed the 3rd use in unsetenv().
>only required moving it within the file. If we are going to "fix" this, the
>only thing I would accept would be to make getenv() completely self contained
>(__findenv() does more than getenv() needs), and move __findenv() into
>setenv.c and then make it static.
This could be done by putting a `static inline char *ifinddev()' in a header
file and outlining it in setenv.c:
static char *ofinddev() { return iffinddev(); }
I actually don't think it's worth inlining either __finddev() or strncmp().
The usual method of comparing the first character would eliminate about
25/26 of the failing calls to strncmp(), and getenv() isn't called all
that often. Note that inlining is often a pessimization, but this doesn't
show up in simple tests because the stuff being tested stays in the cache.
In real use, inlined code often displaces more generally useful code (such
as that for strncmp()) from the cache. The only time inlining is clearly
best is when the inlined code is smaller than the code to call the function.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510180526.PAA12213>