Comments on: Optimization Woes

By: “Micro” Optimizations That Matter | BrandonSavage.net

“Micro” Optimizations That Matter | BrandonSavage.net — Fri, 16 Oct 2009 05:04:46 +0000

[...] of your application, rather than implementing these or any other strategies. You should always solve the business case for optimizations, too. Make sure you know why you’re doing them, and what you’ll gain. [...]

By: Stop Sacrificing Readability For Efficiency! | BrandonSavage.net

Stop Sacrificing Readability For Efficiency! | BrandonSavage.net — Thu, 26 Mar 2009 12:32:37 +0000

[...] argued that micro optimization was a bad idea, from the perspective of unit testing, the idea that “premature optimization is the root of all evil”, the fact that it takes too much time, and that it violates the rules of development and [...]

By: Les

Les — Fri, 13 Mar 2009 14:31:15 +0000

You can still modulise using Procedural Programming but I agree with the point your making – using OOP is the way to go for truly wonderfully decoupled code, etc.

Beside, does any professional web developer *still* develop using Procedural methods today?

Come on… ;)

By: The five immutable rules of optimization » Wahrnehmungen aus zwei Welten

The five immutable rules of optimization » Wahrnehmungen aus zwei Welten — Thu, 12 Mar 2009 22:56:20 +0000

[...] the article PHP micro-optimization tips on his blog. This article has already stirred up some reactions. I want to put some more oil in the fire: while there is nothing wrong with using some of Alex [...]

By: Matthew Purdon

Matthew Purdon — Tue, 10 Mar 2009 16:16:32 +0000

Hey Maggie, I totally agree with your sentiments. I think the real issue with that quote is that some of its meaning has been lost by people shortening it. The original quote is thus:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

I feel very strongly about the fact that people make design decisions based on efficiency over ease of development. Sometimes I wonder if they stick to a more procedural way of developing because they don’t actually grok OOP. It’s hard to see the benefits of object simplicity until you actually try to write things that way.

Statements such as “I don’t want to create too many objects” or “I use static methods for performance” are what keeps PHP out of The Enterprise. It has little to do with PHP itself.

By: Paul M. Jones

Paul M. Jones — Tue, 10 Mar 2009 16:02:19 +0000

“Designing well doesn’t always mean designing for high performance. Instead, it means designing for flexibility and atomicity – you want to be able to easily change things without huge impact on the overall system.”

Preach the Word, sister.

By: tedder

tedder — Tue, 10 Mar 2009 15:22:27 +0000

It’s amazing to see the difference in how optimization is dealt with in industry versus in academia. Yes, optimization is important, knowing how to find the slow points are important (see Amdahl), but just as important is knowing when NOT to optimize or when to throw hardware at a solution.

A good example was when it would take 20 hours to run through a daily log or dataset at our previous company. Yes, if you could move that to 12 hours or 4 hours you would come ahead. However, if it took 3 minutes to run through a day’s worth of data, it didn’t really matter. Developer time is a cost; “spend” it where you need.