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!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!ncar!noao!math.arizona.edu!news.Arizona.EDU!news.Cerritos.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!csusac!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-0408951324110001@192.0.2.1>
Sender: hbaker@netcom13.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>
Date: Fri, 4 Aug 1995 21:24:11 GMT
Lines: 54
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:4972 comp.lang.misc:22497 comp.lang.lisp:18558 comp.object:36347 comp.arch:60127

In article <3vtcud$u4@wcap.centerline.com>, chase@centerline.com (David
Chase) wrote:

> class str {
>    int iCount;
>    char * achData;
> };
> 
> If you're going to be accessing the string in any significant way, it's
> difficult to imagine that the single second indirection will cause you
> any significant loss of efficiency.  Besides which, if you plan to use
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^   <---- We were talking about 3X & greater
> C++, you'd be much better off with something like (and this is still
> pretty low-level, as interfaces go):
> 
> class str {
>   int iCount;
>   char * achData;
> public:
>   inline int length() {return iCount;}
>   inline char * string() {return achData;}
>   str(int n) iCount(n), achData(new char[n]) : { memset(achData, 0, n); }
>   ~str() { delete[] achData; }
> };

David:

You may have missed the start of this thread.  The major complaint is
not in simply _accessing_ the string, although there is definitely a
slowdown associated with that, but with _allocating/deallocating_ the
string.

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.

So the point of the posting was that the Stroustrup/Coplien style
_guarantees_ bad performance, unless you are using class-specific
allocation, in which you still get bad performance (although possibly
not quite as egregious), but now difficult-to-maintain code, as well.

> You should really resist the urge to write your own memory allocator,
> and instead agitate for better ones from vendors.  Or, find another
> vendor.  Or, find one in the public domain written by someone else.

This is the point of the thread, but I was simply pointing out that
Stroustrup/Coplien acknowledge that their school has bad allocator
performance, and recommend that users write their own mallocator.

So you have now gone on record as disagreeing with Stroustrup & Coplien.

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