| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
| First Prev [ 1 2 3 ] Next Last |
Although the word "optimization" shares the same root as "optimal," it is rare for the process of optimization to produce a truly optimal system for all purposes. There will always be tradeoffs.
Optimization must be approached with caution. Tony Hoare stated, and Donald Knuth famously restated, that "Premature optimization is the root of all evil." It is important to first have sound algorithms and a working prototype.
Tasks can often be performed more efficiently. For example, consider the following C code snippet:
int i, sum = 0; for (i = 1; i <= N; i++) sum += i; printf ("sum: %d\n", sum);This code can (assuming no overflow) be rewritten using a mathematical formula like:
sum = (N * (N+1)) / 2; printf ("sum: %d\n", sum);The term "optimization" usually presumes the system retains the same functionality. However, a significant improvement in performance can often be achieved by solving only the actual problem and removing extraneous functionality. For example, if it were reasonable to assume the program does not need to handle more than (say) 100 items of input, one could use static rather than dynamic memory allocation.
Optimization will generally focus on one or two of execution time, memory usage, disk space, bandwidth or some other resource. This will usually require a tradeoff — where one is optimized at the expense of others. For example, increasing the size of cache improves runtime performance, but increase the memory consumption. Other less common tradeoffs include code clarity and conciseness.
In operations research, optimization is the problem of determining the inputs of a function that minimize or maximize its value. Sometimes constraints are imposed on the values that the inputs can take; this problem is known as constrained optimization.
In computer programming, optimization usually specifically means to modify code and its compilation settings on a given computer architectureComputer architecture is the theory behind the design of a computer. In the same way as a building architect sets the principles and goals of a building project as the basis for the draftsman's plans, so too, a computer architect sets out the computer arc to produce more efficient software.
Typical problems have such a large number of possibilities that a programming organization can only afford a "good enough" solution.
Optimization requires finding a bottleneckA bottleneck is literally the neck of a glass or pottery bottle. An hourglass has a bottleneck at its mid-point whose diameter governs the time that granular contents of a given mass will take to pass through. Metaphorically a bottleneck is a section of a: the critical part of the code that is the primary consumer of the needed resource. Improving about 20% of code is often responsible for 80% of the results (see also Pareto principleThe Pareto principle (also known as the 80-20 Rule the law of the vital few and the principle of factor sparsity states that for many phenomena 80% of consequences stem from 20% of the causes. Moreover, among those "top 20" it is also the case that 80% of).
The architectural design of a system overwhelmingly affects its performance. The choice of algorithm affects efficiency more than any other item of the design. More complex algorithms and data structures perform well with many items, while simple algorithms are more suitable for small amounts of data — the setup and initialization time of the more complex algorithm can outweigh the benefit of the better algorithm.
The more memory the program uses, the faster it will generally run. For example, a filtering program will commonly read each line and filter and output that line immediately. This only uses enough memory for one line, but performance is typically poor. Performance can be greatly improved by reading the entire file then writing the filtered result, though this uses much more memory. Caching the result is similarly effective, though also requiring larger memory use.