From: Alan Burch <orotone@...>
Date: 2006-03-13T00:37:55+09:00
Subject: Re: Help me understand why the Ruby block is slower than wit


> This isn't an argument in favor of premature optimization; rather, I'm
> suggesting that having and using some rough-cut knowledge of execution
> speed (as between, say, split and unpack, or something like that)
> isn't premature :-)  Nor is it optimization; it's really melioration.
> 
> 
> David
> 
Thanks David and others who stated what I wanted to say better than I 
did.  Again, I don't think James and I disagree.  I concede that 
premature optimization is not a good thing, but that's not what I was 
trying to do here.  I'm trying to understand Ruby to the level that I 
understand C.  To me that means I know exactly why I use every call, 
every construct.  When I'm able to do this, I'll know Ruby the way I 
want to and I'll be able to use Ruby to accomplish non-trivial tasks. 
Knowing to use a faster or more easily understood construct at the time 
of coding is what one would expect any experience programmer to do. 
Trying to optimze beyond that from the beginning, is silly and 
wrong--just as James pointed out.

Yes, Robert, I assumed that the gets threw an EOFError when it found 
EOF, I just haven't read and understood all I need to yet.  I really 
appreciate all the input on this thread.  It's proved to me that the 
Ruby community is everything good that is being said about it on the 
web.

That said, using the block form is trivially slower, according to the 
time calls that I'm making on my Mac, no matter which solution.  I'm not 
really concerned about that, and agree with Robert's statement above 
about the block being preferred.  To not use the block form would be a 
prime example of premature optimization.

Thanks again for all the input,
Alan

-- 
Posted via http://www.ruby-forum.com/.