Striving for Optimal Performance
  • Blog
    • Archive
    • Categories
    • Search
  • Troubleshooting Oracle Performance
    • Description
    • Structure
    • Table of Contents
    • Forewords
    • Reviews
    • Downloadable Files
    • Addenda and Errata
    • First Edition
  • Public Appearances
    • Past Public Appearances
  • Contact
  • About

Premature Optimization

14 March 2013 7 Comments Written by Christian Antognini

Premature optimization, (probably) because of Donald Knuth’s famous line “premature optimization is the root of all evil,” (see Structured Programming with go to Statements) is, at the very least, a controversial topic. The misconception based on that particular quote is that a programmer, while writing code, should ignore optimization altogether. In my opinion this is wrong. To put the quote in context, let’s have a look to at the text that precedes and follows it:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

My take on Knuth’s paper is that programmers, when writing code, should not care about micro optimization that has local impact only. Instead, they should care about optimizations that have global impact, like the design of a system, the algorithms used to implement the required functionality, or in which layer (SQL, PL/SQL, application language) and with which features a specific processing should be performed. Local optimizations are deferred till a measurement tool points out that a specific part of the code is spending too much time executing. And, because the optimization is local, there is no impact on the overall design of the system.

TOP
Ad: CBO Days 2012 – Final Agenda
ITL Deadlocks (script)

7 Comments

3 Pings/Trackbacks

  1. Laimis N Laimis N
    15 March 2013    

    >Donald Knuth’s famous line “premature optimization is the root of all evil,” (see Structured Programming with go to Statements) is, at the very least, a controversial topic

    Controvercial is the key here! Doland Knuth has used a standard method to draw attention to his statement. This kind of thing is widely used by all writers, journalists, etc.

    Let’s agree that expression like “root of all evil” as far as computers are concerned is quite an artistic one. It has little to do with rigid science. It has to do with conveying ideas to us, humans :)

    Reply
  2. Latest data Industry news round up, Log Buffer #311 Latest data Industry news round up, Log Buffer #311
    18 March 2013    

    […] optimization, (probably) because of Donald Knuth’s famous line “premature optimization is the root of all evil,” (see Structured […]

  3. A Quibble With Martin’s “Optimize Later” Notion | Codecraft A Quibble With Martin’s “Optimize Later” Notion | Codecraft
    27 March 2013    

    […] Premature Optimization (antognini.ch) […]

  4. Peter H. Peter H.
    13 April 2013    

    > “Instead, they should care about optimizations that have global impact, like the design of a system, the algorithms used to implement the required functionality, or in which layer (SQL, PL/SQL, application language) and with which features a specific processing should be performed.”

    Amen to that ! Yet so few project managers and system architects seemed to care when I told them every time a project was starting that they should not plan for the (optional, at best, if there’s still a project budget to spend then) performance tuning for the final stages of a project, but that they should consider them from the very start of the project.

    Well, there’s the struggle for a clean and well performing code on one side, and there’s a project budget on the other side. Compromises, all the time.

    Reply
  5. Top 50 Oracle SQL Blogs for 2016 - Complete IT Professional Top 50 Oracle SQL Blogs for 2016 - Complete IT Professional
    2 May 2016    

    […] Post: Premature Optimisation […]

  6. JMR JMR
    16 August 2017    

    I think what he’s essentially arguing is something that Michael Abrash devoted a whole book to in the 90s (Zen of Code Optimization). Don’t optimize execution paths that don’t need it. Your assumptions about where the performance bottlenecks happen to be are wrong, GUARANTEED. Now take that very code specific concept and begin to apply it a bit more broadly. Your assumptions about where your team or your organization are constrained, are WRONG. Measure, and then improve those measurements. Don’t react without data.

    Reply
  7. andjelko andjelko
    11 March 2019    

    … “quote is that a programmer, while writing code, should ignore optimization altogether..”
    Wrong (Stupid) statement!
    So (if you ignore soft logic) could be True, False, Wrong (Stupid)

    Thanks,
    Andjelko Miovcic

    Reply
  1. Latest data Industry news round up, Log Buffer #311 on 18 March 2013 at 15:32
  2. A Quibble With Martin’s “Optimize Later” Notion | Codecraft on 27 March 2013 at 20:08
  3. Top 50 Oracle SQL Blogs for 2016 - Complete IT Professional on 2 May 2016 at 20:03

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.