in reply to Re^2: Matching First Character of Strings Efficiently (benchmarking)
in thread Matching First Character of Strings Efficiently

tye,
Calculating the ordinal value of $str_a only once was an obvious optimization. I was hurrying to get out of the office - that will teach me.

But I still consider such nano-optimization games to be more a waste than of value.

I completely disagree with you. You don't seem to condemn golfing, which I feel is more of a waste (probably because I am no good at it). It is not like I was complaining that my solution wasn't fast enough. I feel that such games are of value for a few of reasons: Now I am not saying one should sacrifice readability in order to save a few cycles or that a person should spend more programmer time than they will save in run time. As a periodic academic excersise, I see it has a lot of value. Of course, YMMV since you know a lot more than I do.

Cheers - L~R

  • Comment on Re: Re^2: Matching First Character of Strings Efficiently (benchmarking)

Replies are listed 'Best First'.
Re^4: Matching First Character of Strings Efficiently (nano-opt)
by tye (Sage) on Mar 15, 2004 at 23:15 UTC

    Perl Golfing is not an unmixed blessing. But most people are smart enough to realize that golfed solutions aren't usually the best choice when writing code that you care about.

    Unfortunately, many people seem to think that nano-optimized code is the best choice when writing code that you care about. You reinforce this yourself above.

    So, we get people spending way too much time thinking about and arguing about whether they should use substr or ord and then spreading the joy by nano-optimizing other things and in the end they spend an extra 4 hours on their code so that it runs 0.002 seconds faster (yet the total run time is 2.4 seconds).

    It'd be much better if people chose the code that was clear or easy to maintain.

    Just look at how much time has been wasted by people trying to replace s/x//g with tr.

    The cult of nano-optimization is a seductive one. This is why several people have very strong aversion to micro-/nano-optimization.

    - tye