Editing Program optimization (section)

==When to optimize==
<!-- This section is linked from [[Python (programming language)]] -->

Optimization can reduce [[readability]] and add code that is used only to improve the [[Computer performance|performance]]. This may complicate programs or systems, making them harder to maintain and debug. As a result, optimization or performance tuning is often performed at the end of the [[development stage]].

[[Donald Knuth]] made the following two statements on optimization:

<blockquote>"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%"<ref name="autogenerated268">{{cite journal | last = Knuth | first = Donald | citeseerx = 10.1.1.103.6084 | title = Structured Programming with go to Statements | journal = ACM Computing Surveys | volume = 6 | issue = 4 |date=December 1974 | page = 268 | doi = 10.1145/356635.356640 | s2cid = 207630080 }}</ref></blockquote>
(He also attributed the quote to [[Tony Hoare]] several years later,<ref>''The Errors of [[TeX]]'', in ''Software—Practice & Experience'', Volume 19, Issue 7 (July 1989), pp. 607–685, reprinted in his book Literate Programming (p. 276).</ref> although this might have been an error as Hoare disclaims having coined the phrase.<ref><!--Tony Hoare, a 2004 email-->{{Cite web|title=Premature optimization is the root of all evil|url=https://hans.gerwitz.com/2004/08/12/premature-optimization-is-the-root-of-all-evil.html|access-date=2020-12-18|quote=Hoare, however, did not claim it when I queried him in January of 2004|website=hans.gerwitz.com|language=en}}</ref>)
<blockquote> "In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering"<ref name="autogenerated268"/></blockquote>

"Premature optimization" is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.

When deciding whether to optimize a specific part of the program, [[Amdahl's Law]] should always be considered: the impact on the overall program depends very much on how much time is actually spent in that specific part, which is not always clear from looking at the code without a [[Profiling (computer programming)|performance analysis]].

A better approach is therefore to design first, code from the design and then [[profiling (computer programming)|profile]]/[[Benchmark (computing)|benchmark]] the resulting code to see which parts should be optimized. A simple and elegant design <!-- how is this produced, if not prematurely? -->is often easier to optimize at this stage, and profiling may reveal unexpected performance problems that would not have been addressed by premature optimization.

In practice, it is often necessary to keep performance goals in mind when first designing software, but the programmer balances the goals of design and optimization.

Modern compilers and operating systems are so efficient that the intended performance increases often fail to materialize.  As an example, caching data at the application level that is again cached at the operating system level does not yield improvements in execution.  Even so, it is a rare case when the programmer will remove failed optimizations from production code.  It is also true that advances in hardware will more often than not obviate any potential improvements, yet the obscuring code will persist into the future long after its purpose has been negated.