From: Robert Klemme <bob.news@...>
Date: 2004-10-13T18:19:33+09:00
Subject: Re: Ruby Directions (was Re: quality of error messages)


"Markus" <markus@reality.com> schrieb im Newsbeitrag
news:1097598490.20674.93.camel@lapdog.reality.com...
> On Tue, 2004-10-12 at 06:36, Alexander Kellett wrote:
> > On Tue, Oct 12, 2004 at 10:23:12PM +0900, Gavin Sinclair wrote:
> > > Perhaps there are some uses of strings for which immutability makes
> > > performance sense, and some uses for which it doesn't.  I couldn't
be
> > > bothered thinking about it :)
> >
> > i can't imagine many cases where its less performant in fact.
> > immutable strings with cow are obviously far faster for copying
> > than mutable strings and as with most systems its the copy /
> > construction of strings rather than the iteration that takes
> > the time i'd say its logical that they should be immutable.
> > (if you look at the most common c/c++ programs (excepting apps
> >  using trolltech's qt which solves the problem fairly neatly)
> >  you'll see that strcpy and memory allocation take up a huge
> >  chunk of execution time)
> >
> > still... for coding, i love slice! / gsub! etc. they are
> > amazingly useful constructs. i can't imagine living without
> > them :)
>
>      The odd thing is, all you are generally getting with them is a bit
> of syntactic sugar.  Consider the relationship between:
>
>     s = gsub(p,v)
>     s.gsub!(p,v)
>
>     i = i + k
>     i += k

It's not only sugar.  It's different semantics and different performance
(see the other post with the benchmark).  There are enough circumstances
where you don't know whether someone else still holds a reference to an
instance at hand.  As an example, that's the reason why Strings when used
as Hash keys are duped and frozen if they are not yet frozen.

Kind regards

    robert