From: "markus liedl" <markus.lado / gmx.de>
>
> "Bill Kelly" wrote:
> > 
> > From: "markus liedl" <markus.lado / gmx.de>
> > > 
> > > ahmm: you shouldn't think about optimisations, just code in Ruby.
> > 
> > Sounds like a fun task, but, I'm trying to guess as to what practical
> > use this implementation would be expected to be put?
> 
> It will be faster than an optimized one!

Yeah, I'll buy that - and that oceanfront property in Switzerland
you had for sale.  =-)

Perhaps my question didn't reasonably communicate what I was really
wondering.  Is your position that a pure Ruby implementation of a
regexp engine (_whenever_ optimization occurs) will be comparable in
its performance to a C-based implementation (whenever optimization
occurred in _its_ development)?

> >
> > I try to shy away from premature optimization myself, but . . . =)
> >
> 
> Code tends to get more complex if one optimizes.
> Speaking of future: The RubyVM will have different performance
> characteristics than matz' Ruby.
> 
> If somebody has already 'tried' to optimize a bit, it hides _what_ should be
> done. But everybody who tries to optimize afterwards will have a harder
> live.
> 
> You can only optimize for _one_ platform, and RubyInRuby makes limitied
> sense on top of matz' Ruby.
> 
> Don't optimize: Keep the devils out of your head!

The devils in my head would like to file a formal complaint against
this kind of baseless discrimination.

. . . I've been trying to think of a single project I've shipped 
where some form of optimization wasn't deemed necessary to some
part of the code before shipping the thing to real customers.  I
can't think of a single one.

Now in terms of avoiding premature optimization, I think we'd get
along famously.  But my point is that a regexp implementation in
pure Ruby doesn't sound all that useful to me or reasonable unless
there's a legitimate expectation that it'll be able to compete on
performance terms with a 'C' implementation.  Is there?


Regards,

Bill