Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch,comp.lang.c++
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexas.edu!swrinde!tank.news.pipex.net!pipex!howland.reston.ans.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Message-ID: <hbaker-0708951241390001@192.0.2.1>
Sender: hbaker@netcom3.netcom.com
Organization: nil organization
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> <hbaker-0408950815320001@192.0.2.1> <405k8h$emi@news.parc.xerox.com>
Date: Mon, 7 Aug 1995 20:41:39 GMT
Lines: 32
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5008 comp.lang.misc:22541 comp.lang.lisp:18592 comp.object:36465 comp.arch:60191 comp.lang.c++:142684

In article <405k8h$emi@news.parc.xerox.com>, boehm@parc.xerox.com (Hans
Boehm) wrote:

> hbaker@netcom.com (Henry Baker) writes:
> So we're ignoring a potentially exponential complexity difference, and
> we're concentrating on the factor of 2 in the asymptotically inferior
> solution?  Why?

Because for most small strings, your O() arguments are completely washed
out by constant factors.  Most of the concatenation I have seen done
in C programs is done by either sprintf or strcat, and these strings are
typically quite small.  Therefore, the allocation/deallocation overhead
swamps the differences in complexity that you mention.

There are programs that waste a lot of time doing string manipulation.  I
would imagine that most of the Perl-like stuff is quite non-optimal.  If
people aren't using better representations for these kinds of strings,
it's probably because implementing the algorithm as a string-processing
algorithm is not such a hot idea in the first place.  In other words,
someone would be better off changing the algorithm completely, rather
than worrying about some non-optimal string representation.

A good example is symbolic algebra.  You can get along for a while
with a representation that does no sharing at all.  But the hideous
complexity of most symbolic algebra algorithms forces most systems to
utilize better representations.  I'm not sure that a 'string' representation
would ever be competitive with a more sophsticated representation for
symbolic algebra.

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