[ruby-talk:6915] Re: Some performance issues

Wayne Scott wrote:
>
>From: Hugh Sasse Staff Elec Eng <[e-mail]>
[...]
>Another interesting view on how to represent a string that can be
>extened and concat'ed easily is rope in SGI's STL implimentation.
>
>http://www.sgi.com/Technology/STL/Rope.html

That looks neat!  Does it really work as well as the
advertising on the box says?

>Note these non-array versions will require alot of changes to Ruby
>internals. It also makes the RE engine much slower which is probably
>not a good idea for a scripting language.

It may not require nearly as many changes to do it as you
would think.  For several of Ruby's basic types (String,
Array, Hash, etc) provide modules (somewhat like Enumerable)
which list basic operations which can be used to create
your own classes that work just like the built-ins.  Then
to produce new classes with all of the scripting power of
the built-in you just create a class, mix-in the module,
and provide the required methods.

To make it easy make two of the required methods be to_str
and from_str.  Then the difficult bits in the module (like
REs) can be implemented by extracting a native Ruby string,
manipulating it, then converting back to the different
implementation.  So yes, an RE would be slow.  But the cost
is on the order of computing $' and $`.

This is 'tie' in Perl.  Except that what in Perl is
scattered around the internals could in Ruby be implemented
with little or no redesign of the internals.

A benefit of doing this work down the road is that some day
the following optimization could be used internally.  When
an RE matches instead of producing $' and $` by default, tie
the string matched, $', and $` so that any attempt to
change the string matched or access $' or $` will cause
$' and $` to be calculated.  Upon rematching all three ties
are thrown away anyways.

The idea is that a tied wrapper around a regular string
like this should be easy to produce and destroy.  Then
this lets you be lazy about producing $' and $`, which means
that if you don't use it you don't pay for it.  Good old
lazy evaluation. :-)

I mention this optimization not because I think it is a top
priority (though it would be nice) but because leaving the
door open for doing this some day may have a consequence I
am missing.  For instance is it hard to replace the current
object with an object of a different class?

For the record, Perl keeps track of a global flag.  If it
has seen $` or $' anywhere it then computes them on every
match.  Otherwise it doesn't.  I think the tie approach
I described is a much cleaner way to do the optimization.
OTOH a perfectly valid approach to optimization is to
provide efficient versions (like StringScanner) for those
who want them, and then feature-filled versions for those
who don't care.

But where clean designs can go hand in hand with good
algorithms, use them.

Cheers,
Ben
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com