imported>Unixxx: /* False optimization */ - multi core processors were partly developed because scale out (increase cores, parallelism) uses less energy than scale up (increase frequency, serial execution)

2025-12-17T06:19:58Z

False optimization: - multi core processors were partly developed because scale out (increase cores, parallelism) uses less energy than scale up (increase frequency, serial execution)

← Previous revision		Revision as of 06:19, 17 December 2025
Line 14:		Line 14:
	Optimization can occur at a number of levels. Typically the higher levels have greater impact, and are harder to change later on in a project, requiring significant changes or a complete rewrite if they need to be changed. Thus optimization can typically proceed via refinement from higher to lower, with initial gains being larger and achieved with less work, and later gains being smaller and requiring more work. However, in some cases overall performance depends on performance of very low-level portions of a program, and small changes at a late stage or early consideration of low-level details can have outsized impact. Typically some consideration is given to efficiency throughout a project{{snd}} though this varies significantly{{snd}} but major optimization is often considered a refinement to be done late, if ever. On longer-running projects there are typically cycles of optimization, where improving one area reveals limitations in another, and these are typically curtailed when performance is acceptable or gains become too small or costly. Best practices for optimization during iterative development cycles include continuous monitoring for performance issues coupled with regular performance testing.<ref>{{cite web \|title= Performance Optimization in Software Development: Speeding Up Your Applications\|url=https://senlainc.com/blog/performance-optimization-in-software-development/#best-practices-for-performance-optimization \|access-date=12 July 2025}}</ref><ref>{{cite web \|author=Agrawal, Amit \|title= Maximizing Efficiency: Implementing a Performance Monitoring System \|url=https://www.developers.dev/tech-talk/implement-a-system-for-monitoring-application.html \|access-date=12 July 2025}}</ref>		Optimization can occur at a number of levels. Typically the higher levels have greater impact, and are harder to change later on in a project, requiring significant changes or a complete rewrite if they need to be changed. Thus optimization can typically proceed via refinement from higher to lower, with initial gains being larger and achieved with less work, and later gains being smaller and requiring more work. However, in some cases overall performance depends on performance of very low-level portions of a program, and small changes at a late stage or early consideration of low-level details can have outsized impact. Typically some consideration is given to efficiency throughout a project{{snd}} though this varies significantly{{snd}} but major optimization is often considered a refinement to be done late, if ever. On longer-running projects there are typically cycles of optimization, where improving one area reveals limitations in another, and these are typically curtailed when performance is acceptable or gains become too small or costly. Best practices for optimization during iterative development cycles include continuous monitoring for performance issues coupled with regular performance testing.<ref>{{cite web \|title= Performance Optimization in Software Development: Speeding Up Your Applications\|url=https://senlainc.com/blog/performance-optimization-in-software-development/#best-practices-for-performance-optimization \|access-date=12 July 2025}}</ref><ref>{{cite web \|author=Agrawal, Amit \|title= Maximizing Efficiency: Implementing a Performance Monitoring System \|url=https://www.developers.dev/tech-talk/implement-a-system-for-monitoring-application.html \|access-date=12 July 2025}}</ref>

	As performance is part of the specification of a program{{snd}} a program that is unusably slow is not fit for purpose: a video game with 60 Hz (frames-per-second) is acceptable, but 6 frames-per-second is unacceptably choppy{{snd}} performance is a consideration from the start, to ensure that the system is able to deliver sufficient performance, and early prototypes need to have roughly acceptable performance for there to be confidence that the final system will (with optimization) achieve acceptable performance. This is sometimes omitted in the belief that optimization can always be done later, resulting in prototype systems that are far too slow{{snd}} often by an [[order of magnitude]] or more{{snd}} and systems that ultimately are failures because they architecturally cannot achieve their performance goals, such as the [[Intel 432]] (1981); or ones that take years of work to achieve acceptable performance, such as Java (1995), which achieved performance comparable with native code only with [[~~HotSpot (virtual machine)\|~~HotSpot]] (1999).<ref>{{cite web \|author=Düppe, Ingo \|title= Hitchhiker’s Guide to Java Performance: The Past, the Present, and the Future \|url=https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance \|access-date=12 July 2025}}</ref> The degree to which performance changes between prototype and production system, and how amenable it is to optimization, can be a significant source of uncertainty and risk.		As performance is part of the specification of a program{{snd}} a program that is unusably slow is not fit for purpose: a video game with 60 Hz (frames-per-second) might be acceptable, but 6 frames-per-second is unacceptably choppy{{snd}} performance is a consideration from the start, to ensure that the system is able to deliver sufficient performance, and early prototypes need to have roughly acceptable performance for there to be confidence that the final system will (with optimization) achieve acceptable performance. This is sometimes omitted in the belief that optimization can always be done later, resulting in prototype systems that are far too slow{{snd}} often by an [[order of magnitude]] or more{{snd}} and systems that ultimately are failures because they architecturally cannot achieve their performance goals, such as the [[Intel 432]] (1981); or ones that take years of work to achieve acceptable performance, such as Java (1995), which achieved performance comparable with native code only with [[HotSpot]] (1999).<ref>{{cite web \|author=Düppe, Ingo \|title= Hitchhiker’s Guide to Java Performance: The Past, the Present, and the Future \|url=https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance \|access-date=12 July 2025}}</ref> The degree to which performance changes between prototype and production system, and how amenable it is to optimization, can be a significant source of uncertainty and risk.

	===Design level===		===Design level===
Line 29:		Line 29:

	===Source code level===		===Source code level===
	Beyond general algorithms and their implementation on an abstract machine, concrete source code level choices can make a significant difference. For example, on early C compilers, <~~code~~>while(1)</~~code~~> was slower than <~~code~~>for(;;)</~~code~~> for an unconditional loop, because <~~code~~>while(1)</code> ~~evaluated 1~~ and then had a conditional jump which tested if it was true, while <~~code~~>for (;;)</~~code~~> had an unconditional jump . Some optimizations (such as this one) can nowadays be performed by [[optimizing compiler]]s. This depends on the source language, the target machine language, and the compiler, and can be both difficult to understand or predict and changes over time; this is a key place where understanding of compilers and machine code can improve performance. [[Loop-invariant code motion]] and [[return value optimization]] are examples of optimizations that reduce the need for auxiliary variables and can even result in faster performance by avoiding round-about optimizations.		Beyond general algorithms and their implementation on an abstract machine, concrete source code level choices can make a significant difference. For example, on early C compilers, <syntaxhighlight lang="c" inline>while (true)</syntaxhighlight> was slower than <syntaxhighlight lang="c" inline>for (;;)</syntaxhighlight> for an unconditional loop, because <syntaxhighlight lang="c" inline>while (true)</syntaxhighlight> evaluated <code>true</code> and then had a conditional jump which tested if it was true, while <syntaxhighlight lang="c" inline>for (;;)</syntaxhighlight> had an unconditional jump. Some optimizations (such as this one) can nowadays be performed by [[optimizing compiler]]s. This depends on the source language, the target machine language, and the compiler, and can be both difficult to understand or predict and changes over time; this is a key place where understanding of compilers and machine code can improve performance. [[Loop-invariant code motion]] and [[return value optimization]] are examples of optimizations that reduce the need for auxiliary variables and can even result in faster performance by avoiding round-about optimizations.

	===Build level===		===Build level===
Line 62:		Line 62:

	<syntaxhighlight lang="c">		<syntaxhighlight lang="c">
	int i, sum = 0;		int sum = 0;
	for (i = 1; i <= N; ++i) {		for (int i = 1; i <= N; ++i) {
	sum += i;		sum += i;
	}		}
	printf("sum: %d\n", sum);		printf("sum: %d\n", sum);
Line 101:		Line 101:
	<!-- This section is linked from [[Python (programming language)]] -->		<!-- This section is linked from [[Python (programming language)]] -->

	Typically, optimization involves choosing the best overall algorithms and data structures. <ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref> Frequently, algorithmic improvements can cause performance improvements of several orders of magnitude instead of micro-optimizations, which rarely improve performance by more than a few percent. <ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref> If one waits to optimize until the end of the development cycle, then changing the algorithm ~~requires~~ a ~~complete~~ rewrite.		Typically, optimization involves choosing the best overall algorithms and data structures.<ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref> Frequently, algorithmic improvements can cause performance improvements of several orders of magnitude instead of micro-optimizations, which rarely improve performance by more than a few percent.<ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref> If one waits to optimize until the end of the development cycle, then changing the algorithm could require a significant rewrite.

	Frequently, micro-optimization can reduce [[readability]] and complicate programs or systems. That can make programs more difficult to maintain and debug.		Frequently, micro-optimization can reduce [[readability]] and complicate programs or systems. That can make programs more difficult to maintain and debug.
Line 111:		Line 111:
	<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>		<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 often used as a rallying cry against all optimization in all situations for all purposes. <ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref><ref>{{cite web\|url=https://www.javacodegeeks.com/2012/11/not-all-optimization-is-premature.html\|title=Not All Optimization is Premature}}</ref><ref>{{cite web\|url=https://www.infoworld.com/article/2165382/when-premature-optimization-isn-t.html\|title=When Premature Optimization Isn't}}</ref><ref>{{cite web\|url=https://prog21.dadgum.com/106.html\|title="Avoid Premature Optimization" Does Not Mean "Write Dump Code"}}</ref> Frequently, [[SOLID\|Clean Code]] causes code to be more complicated than simpler more efficient code. <ref>{{cite web\|url=https://devshift.substack.com/p/premature-abstractions\|title=Premature Abstractions}}</ref>		"Premature optimization" is often used as a rallying cry against all optimization in all situations for all purposes.<ref>{{cite web\|url=https://ubiquity.acm.org/article.cfm?id=1513451\|title=The Fallacy of Premature Optimization}}</ref><ref>{{cite web\|url=https://www.javacodegeeks.com/2012/11/not-all-optimization-is-premature.html\|title=Not All Optimization is Premature}}</ref><ref>{{cite web\|url=https://www.infoworld.com/article/2165382/when-premature-optimization-isn-t.html\|title=When Premature Optimization Isn't}}</ref><ref>{{cite web\|url=https://prog21.dadgum.com/106.html\|title="Avoid Premature Optimization" Does Not Mean "Write Dump Code"}}</ref> Frequently, [[SOLID\|Clean Code]] causes code to be more complicated than simpler more efficient code.<ref>{{cite web\|url=https://devshift.substack.com/p/premature-abstractions\|title=Premature Abstractions}}</ref>

	When deciding what to optimize, Amdahl's Law should be used to proritize parts based on the actual time spent in a certain part, which is not always clear from looking at the code without a [[Profiling (computer programming)\|performance analysis]].		When deciding what to optimize, Amdahl's Law should be used to proritize parts based on the actual time spent in a certain part, which is not always clear from looking at the code without a [[Profiling (computer programming)\|performance analysis]].
Line 171:		Line 171:
	==False optimization==		==False optimization==

	Sometimes, "optimizations" may hurt performance. ~~Parallelism~~ and ~~concurrency causes a~~ significant overhead performance cost~~, especially~~ energy usage. Keep in mind that C code rarely uses explicit multiprocessing, yet it typically runs faster than any other programming language. Disk caching, paging, and swapping often cause significant increases to energy usage and hardware wear and tear. Running processes in the background to improve startup time slows down all other processes.		Sometimes, "optimizations" may hurt performance. Concurrency and parallelism cause significant overhead performance cost and possibly increased energy usage. Keep in mind that C code rarely uses explicit multiprocessing, yet it typically runs faster than any other programming language. Disk caching, paging, and swapping often cause significant increases to energy usage and hardware wear and tear. Running processes in the background to improve startup time slows down all other processes.

	==See also==		==See also==

imported>Comp.arch at 17:40, 17 November 2025

2025-11-17T17:40:44Z

Show changes

195.14.248.50: /* Design level */

2025-05-14T09:55:32Z

Design level

Show changes

Program optimization - Revision history

imported>Unixxx: /* False optimization */ - multi core processors were partly developed because scale out (increase cores, parallelism) uses less energy than scale up (increase frequency, serial execution)

imported>Comp.arch at 17:40, 17 November 2025

195.14.248.50: /* Design level */