Date: Fri, 19 Dec 1997 12:17:28 -0800 (PST)
From: Dean Gaudet <dgaudet@arctic.org>
To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>
cc: new-httpd@apache.org
Subject: Re: "locale" project
In-Reply-To: <Pine.BSF.3.96.971219224322.627A-100000@ache.relcom.ru>
Message-ID: <Pine.LNX.3.95dg3.971219121046.7873A-100000@twinlark.arctic.org>
Organization: Transmeta Corp.
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Fri, 19 Dec 1997, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote:

> On Fri, 19 Dec 1997, Dean Gaudet wrote:
>=20
> > move this way as well... and as we replace string and alloc functions w=
e
> > venture further and further away from libc.
>=20
> Just two examples from FreeBSD libc:
> string functions are mostly in assembler and malloc functions effecttivel=
y
> talk to kernel VM system to give more optimization and returning memory
> back to VM. All this features will lost with re-implementing :-(
> Ok, ok, I keep silence...

Ah, but writing strcpy and strcat in assembler does not necessary lead to
improved performance.  Consider this (assume there's no buffer overflows):

    void the_libc_way(char *d, char *s1, char *s2)
    {
=09strcpy(d, s1);
=09strcat(d, s2);
    }

    /* here's a function that I found in Lattice C for the Amiga libc,
     * it's strcpy, but returns a pointer to the NUL-terminator of d,
     * which is about 2000 times more useful than returning d.
     */
    char *stpcpy(char *d, const char *s)
    {
=09while((*d =3D *s)) {
=09    ++d;
=09    ++s;
=09}
=09return d;
    }

    void a_faster_way(char *d, char *s1, char *s2)
    {
=09strcpy(stpcpy(d, s1), s2);
    }

The first does 2*|s1|+|s2| work, the second does |s1|+|s2| work.

i.e. optimizing libc isn't going to make the lame code that's written to
use libc go faster.  You can find similar lame examples using strncpy,
and strncat.  Another case that causes extreme lameness is the \0
terminated string itself -- which forces you to make duplicates of
things just so that you can get a token which is \0-terminated to pass
to another routine.  If strings were struct { char *p; size_t len }
this copying wouldn't have to happen.

BTW we still use malloc(), we just wrap it in a bunch of our own stuff.  We
don't ever free() though.

Dean