From: dblack@... Date: 2006-03-12T22:44:07+09:00 Subject: Re: Help me understand why the Ruby block is slower than wit Hi -- On Sun, 12 Mar 2006, James Edward Gray II wrote: > On Mar 11, 2006, at 9:58 AM, Alan Burch wrote: > >> James Gray wrote: >>> On Mar 10, 2006, at 4:57 PM, Alan Burch wrote: >>> >>>> I first saw >>>> that the array class mixed in enumerable and that I could use the to_a >>>> call from there, but a quick check using -r profile showed that my >>>> original call to split was a much quicker way to convert from a string >>>> to an array. >>> >>> This sounds like premature optimization. Remember, you start >>> worrying about speed when the code gets too slow. Not before. >>> >>> James Edward Gray II >> >> James: >> I'm going to have to respectfully disagree. > > Well, I'm pretty darn sure you are in the minority on that one: ;) > > http://www.google.com/search?q=%22premature+optimization%22 But one doesn't want to suppress one's knowledge. When I write a program, if I happen to know that, say: puts a will run faster than: eval "puts #{97.chr}" then I can't really be blamed for using that knowledge, just because the knowledge pertains to speed. In other words, I don't think that avoiding premature optimization means that one should never knowingly take speed into account when choosing what to put in one's code. In fact, I would find it really difficult to do that, because I wouldn't know how to choose among the various alternatives available in a way that paid no attention to execution speed. 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 -- David A. Black (dblack@wobblini.net) Ruby Power and Light, LLC (http://www.rubypowerandlight.com) "Ruby for Rails" chapters now available from Manning Early Access Program! http://www.manning.com/books/black