Re: Re: Re: What is the most efficient perl switch/case statement?

#main system check loop big_airplane_002 

while (1) {
$status = Poll_status_on_hydraulic_systems($wingnumber);
act_on_status($status);
}
[download]

What happens if Poll_status_on_hydraulic_systems uses a switch that runs 2x as slow as another viable choice? You lose polls on the equipment. Not saying that this would ever be done in perl (go go ADA) but you get the drift. The statement that programers time is more valuable than CPU is just silly. If you want to rationalize passing the buck by being a lazy programmer go for it. Its not for me.

-Waswas

Comment on Re: Re: Re: What is the most efficient perl switch/case statement? Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: What is the most efficient perl switch/case statement? by perrin (Chancellor) on Nov 21, 2003 at 18:43 UTC
Sorry, using an extreme case which involves something that no one would actually do in Perl anyway does not disprove the point that programmers should typically be more concerned about readability than speed when dealing with micro-optimizations like this one. Sure, you can find some case where a switch statement would make a difference, but it will be very rare. A reasonable approach to performance is to pick a good high-level architecture, write your program in a clear and readable way, profile it to find trouble spots, and fix them. Writing something that is hard to read from the beginning just because a confusing-looking switch statement ran a microsecond faster than the clearer one is not a good programming practice in any language.	[reply]
Rex6: What is the most efficient perl switch/case statement? by waswas-fng (Curate) on Nov 21, 2003 at 20:28 UTC
I guess my point is that when you take that methodology to an extreme and make blanket statements about optimizing code you really just push the responsibility of the code performing well off to the next guy. I can think of 15 or 20 reasons why the OP would want to optimize the switch for best performance. I mean come on lets say you had a tight loop to pass chunks off a queue, a 50% or better performance boost would well be worth it. Sure, don't take optimization to an extreme and try to use the fastest print statement or whatever where id does not make a difference. I am just kind of sick of people jumping down on posters who ask about optimizations -- it seems many people here automatically think that ever question about them is mico-worthless-wastedtime-opimizations right off the bat. I know I have had many times where I have cut down the running time of my programs by 300 percent just by spending a few minutes looking at the core areas and optimizing. Hell look at demerphq's phone prefix problem -- he cut off huge runtimes by changing the way he looked at data. At some point you as a programmer have to take the onus in your work to not toss code speed issues to the hardware guys just because you think your time is more valuable than cpu cycles. using your logic, I would have to see myself keep saying "where is that bubble sort sub I had sitting around here, Its easy for me to read/understand/maintain therefore i must use it unless I have damn good reason not to." Bottom line is don't over optimize but don't be oblivious to easy readable optimizations. -Waswas	[reply]
Re: Rex6: What is the most efficient perl switch/case statement? by perrin (Chancellor) on Nov 21, 2003 at 22:31 UTC
I care a great deal about the performance of my programs, but I try to spend my time wisely. There is a huge difference between studying and modifying a working program in order to speed it up, and worrying about very small things before your program is working. I do the former frequently and encourage it, but try to avoid the latter. The most obvious reason is that it's very hard to predict where your bottlenecks will be before you have a working program, and you may end up making a section of code very hard to read (and spending a lot of time on it) for little or no gain. So, optimize away, but don't do it where it isn't needed.	[reply]