Algorithmic Complexity
Complexity describes how an algorithm’s time and memory grow with problem size, which decides what is feasible at scale.
How cost scales
Two algorithms can both solve a problem yet behave completely differently as the problem grows. Algorithmic complexity, written in big-O notation, captures how running time or memory scales with input size, ignoring constant factors to focus on growth.
Common growth rates
- O(n): linear — cost doubles when the input doubles.
- O(n log n): typical of good sorting; near-linear in practice.
- O(n²): quadratic — becomes painful for large inputs.
- O(2ⁿ): exponential — infeasible beyond small inputs.
Why it decides feasibility
A quadratic algorithm may be fine for a thousand elements and hopeless for a million. When a fusion design sweep or a mesh solve involves millions of unknowns, the difference between an O(n log n) and an O(n²) method is the difference between minutes and never finishing. Choosing the right algorithm can matter more than faster hardware.
Time versus memory
Complexity applies to memory as well as time, and the two often trade off. Storing precomputed results speeds a calculation but uses more memory; recomputing saves memory but costs time. Engineering means choosing the balance the hardware and deadline allow.
Constants still matter
Big-O hides constant factors, which can dominate at realistic sizes. An algorithm with better asymptotic complexity but a huge constant may lose to a simpler one in practice. So complexity guides the choice, but measured performance on real inputs confirms it — analysis and benchmarking together.