Algorithmic efficiency

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages) This article needs more citations. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Algorithmic efficiency" – news · newspapers · books · scholar · JSTOR (January 2024) (Learn how and when to remove this message) This article's style of writing may not reflect the encyclopedic tone used on Wikipedia. See Wikipedia's guide to writing better articles for suggestions. (January 2024) (Learn how and when to remove this message) Property of an algorithm (Learn how and when to remove this message)

In computer science, algorithmic efficiency is a property of an algorithm which relates to the amount of computational resources used by the algorithm. Algorithmic efficiency can be thought of as analogous to engineering productivity for a repeating or continuous process.

For maximum efficiency it is desirable to minimize resource usage. However, different resources such as time and space complexity cannot be compared directly, so which of two algorithms is considered to be more efficient often depends on which measure of efficiency is considered most important.

For example, cycle sort and Timsort are both algorithms to sort a list of items from smallest to largest. Cycle sort organizes the list in time proportional to the number of elements squared (${\textstyle O(n^{2})}$, see big O notation), but minimizes the writes to the original array and only requires a small amount of extra memory which is constant with respect to the length of the list (${\textstyle O(1)}$). Timsort sorts the list in time linearithmic (proportional to a quantity times its logarithm) in the list's length (${\textstyle O(n\log n)}$), but has a space requirement linear in the length of the list (${\textstyle O(n)}$). If large lists must be sorted at high speed for a given application, timsort is a better choice; however, if minimizing the program/erase cycles and memory footprint of the sorting is more important, cycle sort is a better choice.

Background

The importance of efficiency with respect to time was emphasized by Ada Lovelace in 1843 as applied to Charles Babbage's mechanical analytical engine:

"In almost every computation a great variety of arrangements for the succession of the processes is possible, and various considerations must influence the selections amongst them for the purposes of a calculating engine. One essential object is to choose that arrangement which shall tend to reduce to a minimum the time necessary for completing the calculation"^[1]

Early electronic computers had both limited speed and limited random-access memory. Therefore, a space–time trade-off occurred. A task could use a fast algorithm using a lot of memory, or it could use a slow algorithm using little memory. The engineering trade-off was therefore to use the fastest algorithm that could fit in the available memory.

Modern computers are significantly faster than early computers and have a much larger amount of memory available (gigabytes instead of kilobytes). Nevertheless, Donald Knuth emphasized that efficiency is still an important consideration:

"In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal and I believe the same viewpoint should prevail in software engineering"^[2]

In the era of AI, while LLMs can generate code that works, these often fall short of the performance standards required in resource-constrained or time-sensitive applications^[3], making code efficiency a critical bottleneck for real-world deployment.

Overview

An algorithm is considered efficient if its resource consumption, also known as computational cost, is at or below some acceptable level. Roughly speaking, 'acceptable' means: it will run in a reasonable amount of time or space on an available computer, typically as a function of the size of the input. Since the 1950s computers have seen dramatic increases in both the available computational power and in the available amount of memory, so current acceptable levels would have been unacceptable even 10 years ago. In fact, thanks to the approximate doubling of computer power every 2 years, tasks that are acceptably efficient on modern smartphones and embedded systems may have been unacceptably inefficient for industrial servers 10 years ago.

Computer manufacturers frequently bring out new models, often with higher performance. Software costs can be quite high, so in some cases the simplest and cheapest way of getting higher performance might be to just buy a faster computer, provided it is compatible with an existing computer.

There are many ways in which the resources used by an algorithm can be measured: the two most common measures are speed and memory usage; other measures could include transmission speed, temporary disk usage, long-term disk usage, power consumption, total cost of ownership, response time to external stimuli, etc. Many of these measures depend on the size of the input to the algorithm, i.e. the amount of data to be processed. They might also depend on the way in which the data is arranged; for example, some sorting algorithms perform poorly on data which is already sorted, or which is sorted in reverse order.

In practice, there are other factors which can affect the efficiency of an algorithm, such as requirements for accuracy and/or reliability. As detailed below, the way in which an algorithm is implemented can also have a significant effect on actual efficiency, though many aspects of this relate to optimization issues.

Theoretical analysis

In the theoretical analysis of algorithms, the normal practice is to estimate their complexity in the asymptotic sense. The most commonly used notation to describe resource consumption or "complexity" is Donald Knuth's Big O notation, representing the complexity of an algorithm as a function of the size of the input ${\textstyle n}$. Big O notation is an asymptotic measure of function complexity, where ${\textstyle f(n)=O{\bigl (}g(n){\bigr )}}$ roughly means the time requirement for an algorithm is proportional to ${\displaystyle g(n)}$, omitting lower-order terms that contribute less than ${\displaystyle g(n)}$ to the growth of the function as ${\textstyle n}$ grows arbitrarily large. This estimate may be misleading when ${\textstyle n}$ is small, but is generally sufficiently accurate when ${\textstyle n}$ is large as the notation is asymptotic. For example, bubble sort may be faster than merge sort when only a few items are to be sorted; however either implementation is likely to meet performance requirements for a small list. Typically, programmers are interested in algorithms that scale efficiently to large input sizes, and merge sort is preferred over bubble sort for lists of length encountered in most data-intensive programs.

Some examples of Big O notation applied to algorithms' asymptotic time complexity include:

Notation	Name	Examples
${\displaystyle O(1)}$	constant	Finding the median from a sorted list of measurements; Using a constant-size lookup table; Using a suitable hash function for looking up an item.
${\displaystyle O(\log n)}$	logarithmic	Finding an item in a sorted array with a binary search or a balanced search tree as well as all operations in a Binomial heap.
${\displaystyle O(n)}$	linear	Finding an item in an unsorted list or a malformed tree (worst case) or in an unsorted array; Adding two n-bit integers by ripple carry.
${\displaystyle O(n\log n)}$	linearithmic, loglinear, or quasilinear	Performing a Fast Fourier transform; heapsort, quicksort (best and average case), or merge sort
${\displaystyle O(n^{2})}$	quadratic	Multiplying two n-digit numbers by a simple algorithm; bubble sort (worst case or naive implementation), Shell sort, quicksort (worst case), selection sort or insertion sort
${\displaystyle O(c^{n}),\;c>1}$	exponential	Finding the optimal (non-approximate) solution to the travelling salesman problem using dynamic programming; determining if two logical statements are equivalent using brute-force search

Measures of resource usage

Measures are normally expressed as a function of the size of the input ${\displaystyle \scriptstyle {n}}$.

The two most common measures are:

• Time: how long does the algorithm take to complete?
• Space: how much working memory (typically RAM) is needed by the algorithm? This has two aspects: the amount of memory needed by the code (auxiliary space usage), and the amount of memory needed for the data on which the code operates (intrinsic space usage).

For computers whose power is supplied by a battery (e.g. laptops and smartphones), or for very long/large calculations (e.g. supercomputers), other measures of interest are:

• Direct power consumption: power needed directly to operate the computer.
• Indirect power consumption: power needed for cooling, lighting, etc.

As of 2018^[update], power consumption is growing as an important metric for computational tasks of all types and at all scales ranging from embedded Internet of things devices to system-on-chip devices to server farms. This trend is often referred to as green computing.

Less common measures of computational efficiency may also be relevant in some cases:

• Transmission size: bandwidth could be a limiting factor. Data compression can be used to reduce the amount of data to be transmitted. Displaying a picture or image (e.g. Google logo) can result in transmitting tens of thousands of bytes (48K in this case) compared with transmitting six bytes for the text "Google". This is important for I/O bound computing tasks.
• External space: space needed on a disk or other external memory device; this could be for temporary storage while the algorithm is being carried out, or it could be long-term storage needed to be carried forward for future reference.
• Response time (latency): this is particularly relevant in a real-time application when the computer system must respond quickly to some external event.
• Total cost of ownership: particularly if a computer is dedicated to one particular algorithm.

See also

• Analysis of algorithms—How to determine the resources needed by an algorithm.
• Benchmark—A method for measuring comparative execution time and space in defined cases.^[10][11][12]
• Best, worst and average case—Considerations for estimating execution times in three scenarios.
• Compiler optimization—Compiler-derived optimization.
• Computational complexity theory
• Computer performance—Computer hardware metrics.
• Empirical algorithmics—The practice of using empirical methods to study the behavior of algorithms.
• Outline of algorithms
• Program optimization
• Performance analysis—Methods of measuring actual performance of an algorithm at run-time.

References