Comments on: Why optimizing without profiling is inefficient

By: mawi

mawi — Sat, 06 Jan 2007 14:38:37 +0000

As Brad almost writes, I think there is (atleast?) an important third factor, which is developer time or initial investment cost, if you prefer. You can write optimized and readable code, but it brings a higher initial expense. Which usually is fine, enter other tradeoffs.

By: AntonioGanci

AntonioGanci — Wed, 29 Nov 2006 14:44:17 +0000

Il problema delle ottimizzazioni premature…

…

By: Brad Bellomo

Brad Bellomo — Mon, 27 Nov 2006 20:31:47 +0000

Everyone always says this is a trade off (readability-optimization), but I don’t agree. Most production code can be redesigned to be both more readable and faster. Poor optimization will make code less readable, but can also make it slower.

Rico Mariani’s top ten list is clever, but I wouldn’t use Microsoft as my standard for optimization – almost every product they have is ridiculously slow.

Developers SHOULD write code trying to make everything run fast. As long as you ignore trivialities (i.e. code with fewer comments compiles 0.0001% faster) and know how to optimize (some understanding of how the compiler, OS, and hardware work) there are very few trade offs between readability and optimization. And telling the developers to favor readability over optimization solves these.

There is a very real trade off between developer time spent writing code and optimization. Developers understand which is appropriate, so this isn’t a problem.

By: Lloyd Budd

Lloyd Budd — Mon, 27 Nov 2006 19:21:27 +0000

Measure early and often (automate)

By: Rob Whelan

Rob Whelan — Sat, 25 Nov 2006 22:07:38 +0000

You’re absolutely correct that many developers tend to optimize prematurely — and not just the inexperienced developers; sometimes the more experienced developers have built up a big bag of optimization “tricks” that they fill their code with (sometimes more to impress the junior developers than anything else!)… ignoring the fact that they’re making their code far less readable for a negligible performance gain.

But it’s also an awful idea to put performance and resource usage out of your mind completely until basic development is complete and you’re running tests. If you ignore scalability and performance in your basic application design, it’s easy to cook up a design that’s very clear and easy to follow, but will be totally unworkable in your final product; either memory demands will be enormous for even simple uses, or scaling up to thousands of users will be impossible, etc. — and flaws in your core design are much, much harder to correct at that point.

This is where I feel the concept of elegance really comes into play in software design and code. A very simple design can easily result in an extremely inefficient implementation; a design for optimum performance is often painfully complex; a truly elegant design (like elegant code) is easy to understand and avoids arcane tricks, but is also concise and efficient.

This is also where simple research comes into play. To use your checkout counter example — if you’d watched a few other people check out before you built your own plan, you would have understood the general problem before you started. Walking through a general design and making estimations on usage levels, memory requirements, etc. based on performance testing on past projects and research can be invaluable far before you have any code you can test.

By: Johannes

Johannes — Fri, 24 Nov 2006 22:13:18 +0000

Hey, those ten optimisation rules sure has some similarities to the ten focus points of Microsoft:

1. Developers
2. Developers
3. Developers
4. Developers
5. Developers
6. Developers
7. Developers
8. Developers
9. Developers
10. Developers

By: Andres

Andres — Fri, 24 Nov 2006 08:49:38 +0000

Kartik:
If the performance of the system is such that it’s not usable, changing the code to become faster, and less readable is ok. But it has to be a decision based on facts, not on guessing.

Cale:
I think you are right. Using an appropiate algorithm on a problem is usually the best way to get decent performance. The main point I’m making is still valid though – if you have to sort a list that will never contain more than 10 items, using a fast, but advanced and hard to read algorithm might be an overkill.

By: Cale

Cale — Fri, 24 Nov 2006 02:41:10 +0000

As another point to this, when you need to optimise, it’s usually better to make algorithmic optimisations where possible rather than trying to make lower-level changes to the operation of small pieces. Most often, slowdowns are caused by just using the wrong algorithm or data structures. For example, replacing an association list with a proper finite map implementation using balanced binary trees internally will usually speed things up immensely, and often provide a nicer interface to the functionality that was provided by the association lists, potentially increasing the readability of the code. The same goes for lists which are being used as sets — if you’re not just iterating over it, and instead have to do lots of things like intersections, or large amounts of element testing, you’re better off with a proper set library.

By: Kartik Agaram

Kartik Agaram — Thu, 23 Nov 2006 00:22:48 +0000

Even if you measure and make sure a component needs optimizing, don’t base the optimizations you use on just the performance improvement you get. You still have to think about readability tradeoffs. Performance improvements are transient effects, and the inevitable changes to the software or hardware stack below your application will likely reduce these improvements. But if you obtain these transient improvements using really unreadable code you will be forever saddled with it because nobody will want to take the trouble to understand it.