Pre-Mature Optimization

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Pre-Mature Optimization

Post by Christopher »

feyd rightly pointed out that the OT pre-mature optimization comments in the single-double quote thread had gone too far (darn him! :twisted:). But it is an interesting topic because I think there is more agreement than you might think, but people come come at it from different perspectives. I would propose that there are three related activities with fuzzy borders involved in this conversation.

1. Simply writing efficient code. That means selecting the best coding practices and algorithms the programmers knows to solve the current problem -- based on your knowledge of the problem.

2. Optimization. That means improving code to improve performance. There seems to be an implication that there is more information available now than when the original code was written.

3. Pre-mature Optimization. That means attempting to improve code without knowing whether there are really performance problems and/or without sufficient knowledge to know whether the changes will actually improve performance.
(#10850)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Re: Pre-Mature Optimization

Post by Roja »

Here are two examples that should clarify things a bit.

Bob writes a program and makes sure that everywhere he can, he writes the most optimal code he can. Unfurling loops, rewriting libraries, trimming overhead at every possible location.

However, Bob leaves dozens of bug reports lingering because he's too busy writing the most optimal code possible. Worse, fewer and fewer people are using it because their bugs aren't being fixed. In the end, it doesn't even matter because Bob's program runs fine on the majority of hosts, and doesn't suffer from performance problems.

Bob is definitely pre-maturely optimizing.

But now consider Steve. Steve has a set of coding guidelines that he follows because they feel more comfortable to him. Simple things like avoiding large arrays, releasing memory when he's done with it, and heck, even indenting consistently.

Steve doesn't spend a huge amount of time "optimizing", its just part of how he codes. While he may leave some loops curled (costing him in performance), and he may use libraries that aren't perfectly optimized, he's on top of things.

Steve has time to fix bugs, has time to add new features, and even looks at replacement libraries that could improve things.

Is Steve pre-maturely optimizing?

Some would argue that he is. He doesn't "know" that he "needs" to avoid large arrays, and maybe the code would be more maintainable if he didn't. He hasn't commented on how his code performs.. maybe its horribly slow on the majority of systems. Maybe he doesn't even know that it is!

My point is that there is a fine line between good programming practice, and sliding down the slope into premature optimization. Testing certainly plays a big role, and prioritizing does too. Where the right balance is, no one can really say. Its a matter of opinion.

Sadly, I can't claim to be either Steve or Bob. Much like Steve, I don't go out of my way to optimize, but like Bob, I don't seem to have enough time to fix all the bugs in my code. Maybe I'm the wrong person to answer as a result. :)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Pre-Mature Optimization

Post by alex.barylski »

arborint wrote:feyd rightly pointed out that the OT pre-mature optimization comments in the single-double quote thread had gone too far (darn him! :twisted:). But it is an interesting topic because I think there is more agreement than you might think, but people come come at it from different perspectives. I would propose that there are three related activities with fuzzy borders involved in this conversation.

1. Simply writing efficient code. That means selecting the best coding practices and algorithms the programmers knows to solve the current problem -- based on your knowledge of the problem.

2. Optimization. That means improving code to improve performance. There seems to be an implication that there is more information available now than when the original code was written.

3. Pre-mature Optimization. That means attempting to improve code without knowing whether there are really performance problems and/or without sufficient knowledge to know whether the changes will actually improve performance.
I would say that about sums it up... 8)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

It is an interesting subject because it does hit close to home for programmers. Take Roja's Bob and Steve -- the two key statements about them for me are:
Roja wrote:Bob writes a program and makes sure that everywhere he can, he writes the most optimal code he can. Unfurling loops, rewriting libraries, trimming overhead at every possible location.
It is the "most optimal code he can" part where people disagree where to draw the line. Obviously you should try to write "optimal" code. Often when you do this you are actually improving the code. On the other hand, sometimes "optimal" code is not so optimal or worse it forces other design decisions that create a cascade of bad design decisions.
Roja wrote:Steve has a set of coding guidelines that he follows because they feel more comfortable to him.
This is an interesting one because we are all guilty of it. We all have our own conventions that we have become "comfortable" with. But do we have sufficient perspective to question our own conventions each time we do a design? The fact that all of our "conventions" evolve over time shows that we do have some sort of internal review process.
(#10850)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Personally, before I start a project I try and estimate overall execution time goal, and if that goal is not met then optimizing occurs. Aside from that, if I know something is faster than something else, ereg vs preg for instance, then I'll use it.. other than that I don't really think about it. Perhaps I'll note that certain classes could be more efficient, but if the overall scheme of things is as fast as my set goal, then great, move on. If my goal was not met, then I'll go down the list of slowest classes until my goal was met.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jcart wrote:... other than that I don't really think about it.
This is a wonderfully Agile statement when it comes from an experienced programmer like Jcart. You create a design and performance target, then you proceed with implementing it without trying to predict the future too much. When done reassess, rinse and repeat.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Personally, before I start a project I try and estimate overall execution time goal, and if that goal is not met then optimizing occurs. Aside from that, if I know something is faster than something else, ereg vs preg for instance, then I'll use it.. other than that I don't really think about it. Perhaps I'll note that certain classes could be more efficient, but if the overall scheme of things is as fast as my set goal, then great, move on. If my goal was not met, then I'll go down the list of slowest classes until my goal was met.
I agree. Experience should be allowing me to optimise on the trot when it comes to the usual suspects. Anything which requires further thought will usually get identified when I have working code. I don't see the point of obsessing over every line until I can literally measure it. I wouldn't usually select classes, just the slowest 5 class methods (overall, and ignoring database abstraction usually). Most of the time they'll be responsible for most larger issues. After that I may just cherry-pick based on the frequency of method calls and their aggregate time in execution.

Very rarely will it result in syntax changes. I tend towards readable code over (possibly) more optimal code. Makes it perhaps a little slower, but far easier to navigate and modify on a whim. Which is more valuable? The ability to execute faster, or the ability to re-use elements and adapt them quickly?

I think the key thought in there - and in Jcart's post - is not hitting the optimisation bandwagon without some form of performance measurements. Otherwise you have no idea where you should be optimising first and wind up wasting time on areas which are neglible. Even an overview gives a few hints.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

I don't really go back looking to optimize unless something is running very slow and then it is classified as a bug. I usually have everything well enough documented that I catch and identify any potential slow spots well before coding starts.
Post Reply