Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!news.bu.edu!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!newsfeed.internetmci.com!news.uoregon.edu!news.bc.net!unixg.ubc.ca!info.ucla.edu!library.ucla.edu!news.ucdavis.edu!csus.edu!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Message-ID: <hbaker-0708950804440001@192.0.2.1>
Sender: hbaker@netcom12.netcom.com
Organization: nil organization
References: <jyvgwh@bmtech.demon.co.uk> <807474453snz@wildcard.demon.co.uk> <3vssnd$hd0@news.cs.tu-berlin.de> <3vtcud$u4@wcap.centerline.com> <hbaker-0408951324110001@192.0.2.1> <jywahs@bmtech.demon.co.uk>
Date: Mon, 7 Aug 1995 16:04:44 GMT
Lines: 49
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:4992 comp.lang.misc:22527 comp.lang.lisp:18579 comp.object:36438 comp.arch:60161

In article <jywahs@bmtech.demon.co.uk>, Scott Wheeler
<scottw@bmtech.demon.co.uk> wrote:

> In Article <hbaker-0408951324110001@192.0.2.1> Henry Baker writes:
> >The Stroustrup/Coplien school advocates using 2 mallocated objects in 
> >C++ when one will do in C, and this thread already described many of 
> >the horrors of malloc inefficiencies.
> 
> Only one allocation of heap memory (not *malloc*, please - that's C) 
> unless you are using "new" to generate the string, because the top 
> level of the object will go on the stack. Since temporaries and 
> automatic variables go on the stack, this makes a substantial 
> difference.

Excuse me??  You should read the Stroustrup/Coplien books again.  They
suggest newing/mallocating everything, & putting ref counts in the string
'headers'.  Your scheme could conceivably work, if one were willing to
copy around both the ptr to the string chars _and_ the length field, but
such an implementation would make a string 'handle' bigger than a usual
C++ pointer, and thereby cause a number of other problems with the C++
type system.  Furthermore, one would _not_ want to copy any ref counts
with such a scheme. In any case, I haven't seen this particular variant
recommended in any of the usual books.

> >So the point of the posting was that the Stroustrup/Coplien style
> >_guarantees_ bad performance, 
> 
> I've yet to see any hard data posted. The 3x quoted repeatedly here has 
> not yet been shown to be more than a guess.

The double allocator hit would be 2X by itself, all other things being
equal.  If the potentially greater fragmentation of the free list caused
a lengthening of freelist searches, then this would show up in further reduced
allocator and deallocator performance.

Accessing the string itself is at least 2X slower, due to the double
indirection.

As Paul Wilson pointed out, the 'rounding up' of each object to at least
16 bytes could cost severely in memory hierarchy costs (caching, VM, etc.),
and such costs would be most evident in the case where most strings were
short (i.e., <16 bytes, the most usual case).

Yes, my 3x guess is just a guess, but a well-educated guess based on
lots & lots of experience.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
