Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!newsfeed.internetmci.com!EU.net!Germany.EU.net!news.dfn.de!news.uni-augsburg.de!lrz-muenchen.de!uni-regensburg.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!xlink.net!slsv6bt!news
From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
In-Reply-To: hbaker@netcom.com's message of Wed, 9 Aug 1995 16:21:15 GMT
Message-ID: <KANZE.95Aug10172327@slsvhdt.lts.sel.alcatel.de>
Lines: 93
Sender: news@lts.sel.alcatel.de
Organization: SEL
References: <9507261647.AA14556@aruba.apple.com> <3v8g7l$cge@jive.cs.utexas.edu>
	<3vac07$ptf@info.epfl.ch> <3vb382$dtr@jive.cs.utexas.edu>
	<3vbl70$bht@fido.asd.sgi.com> <hbaker-3107951026250001@192.0.2.1>
	<justin-0108951458440001@158.234.26.212> <hbake
	<jyuynr@bmtech.demon.co.uk> <hbaker-0208950816000001@192.0.2.1>
	<jyvgwh@bmtech.demon.co.uk> <3vr85r$758@fido.asd.sgi.com>
	<KANZE.95Aug9150054@slsvhdt.lts.sel.alcatel.de>
	<hbaker-0908950821150001@192.0.2.1>
Date: 10 Aug 1995 15:23:26 GMT
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5037 comp.lang.misc:22615 comp.lang.lisp:18643 comp.object:36633 comp.arch:60324

In article <hbaker-0908950821150001@192.0.2.1> hbaker@netcom.com
(Henry Baker) writes:

|> In article <KANZE.95Aug9150054@slsvhdt.lts.sel.alcatel.de>,
|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

|> > Interestingly enough, there is a legal (and safe) way of implementing
|> > this same idiom in C++.  It's so ugly, though, that I'm not going to
|> > post it.  (I know, if you were worried about ugliness, you wouldn't be
|> > using C++ anyway:-).)

|> Go ahead & post it!  Hit us with your ugly stick!  We're adults, and
|> we've turned off the V-chip...

Just the essentials (and ignoring eventual reference counting):

    class StringImpl
    {
    public :
        static StringImpl*  mkStringImpl( int length ) ;
        char*               buffer() ;

        void*               operator new( size_t s , int length ) ;
        void                operator delete( void* ) ;
    private :
                            StringImpl( int length ) ;
        int                 theLength ;
    } ;

    StringImpl*
    StringImpl::mkStringImpl( int length )
    {
        return new( length ) StringImpl( length ) ;
    }

    char*
    StringImpl::buffer()
    {
        return (char*)( this + 1 ) ;
    }

    void*
    StringImpl::operator new( size_t s , int length )
    {
        assert( s == sizeof( StringImpl ) ) ;
        return ::operator new( s + length ) ;
    }
    void
    StringImpl::operator delete( void* p )
    {
        ::operator delete( p ) ;
    }

    StringImpl::StringImpl( int length )
        :   theLength( length )
    {
    }

The purpose of the private constructor (and the static mkStringImpl)
is to ensure that 1) all elements *are* created on the heap, and 2)
the extra parameter to new and the parameter to the constructor are
identical.  (Safety, in sum.)

In my tests, all of the functions were made inline.

|> > |>   This way, both the length and then data are allocated together in
|> the heap. And
|> > |> you haven't limited the max length artifically. (I suspect most BASIC
|> systems do
|> > |> this.)
|> > 
|> > I once ran benchmarks (with a very simple program, so probably not
|> > indicative of anythinkg) of three reference counted implementations of
|> > C++ strings: the classical one, the classical one with operator new
|> > overloaded for the fixed length header class, and one using the above
|> > ugly hack (and so only one allocation per string).  Under Solaris,
|> > using the standard system malloc (called directly by new), there was
|> > no significant difference in runtime.

|> We may be interested in these results after we've seen the program.

I don't have the benchmark anymore, and forget exactly what I tested
(in addition to just making the strings).  I do remember being
surprised by the results, since the malloc under SunOS 4 is not
particularly efficient when a lot of small blocks are being allocated.

-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung


