* Glenn Parker (Mar 20, 2005 13:40):
> > Well, with slice!, you have to do more work than doing a slice.  The
> > reason is that you have to paste together the parts that are still a
> > part of the string.  With slice you simply return the substring.

> Seems to me that the same logic should apply to gsub vs. gsub!, but it
> doesn't quite work out that way.  A gsub benchmark using different
> lengths of input and output might be more appropriate.

Hm, yeah, that seems reasonable.

> An aside: I do not accept the assertion that Strings should only be
> used when they can be kept short.  I still expect reasonably good
> performance when operating on large pieces of text all at once, e.g. a
> large file or some other text-based data such as MIME or XML data.

Well, the problem is that a String is represented by one long sequence
of bytes in memory.  That will be slow no matter what you do if the
String is very large.  (Well, slow may be an overstatement, but it will
become the dominating factor.)

> > A comment on your benchmark: doesn't it make more sense to do the
> > tests on new strings each time?

> For the destructive methods, definitely.  For the non-destructive
> methods, it's irrelevant.

Precisely.

> > I'm not arguing with the fact that for most methods, the destructive
> > version will be faster.  I'm just saying that the performance
> > difference between the two isn't that big,

> I still see a lot of cases in your results where the destructive
> method is roughly twice as fast.  That is significant.

Not really.  It only plays a role for very large iterations and I'd say
that by then you'd probably be better off optimizing something else,
        nikolai

-- 
::: name: Nikolai Weibull    :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA    :: loc atm: Gothenburg, Sweden    :::
::: page: minimalistic.org   :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}