| Complexity | Type | Operations | Visual |
|---|---|---|---|
| O(1) | Constant | 1 | |
| O(n) | Linear | 1000 | |
| O(n log n) | Linearithmic | 9.97K | |
| O(n²) | Quadratic | 1000.00K |
Common Algorithm Examples
What is Big O Calculator?
Big O notation describes how an algorithm's runtime grows as input size increases. It's the standard way to compare algorithm efficiency, focusing on worst-case or average-case behavior. For example, O(n) means the algorithm's time scales linearly with input size - doubling input doubles runtime. O(1) means constant time regardless of input size. Understanding Big O helps you choose the right algorithm for your data scale.
How to Use
- Select an input size using preset buttons or enter a custom value.
- Choose which complexities to compare by clicking the buttons.
- The table shows exact operations required for each complexity.
- Visual bars help compare relative performance (logarithmic scale).
- Estimated time shows real-world impact at 1 billion ops/sec.
- Use the examples section to match algorithms to their complexities.
Why Use This Tool?
Tips & Best Practices
- O(n²) algorithms work fine for small inputs but fail at scale
- A million-item array with O(n²) needs 1 trillion operations
- O(log n) is almost as good as O(1) for practical input sizes
- Always consider your expected input size when choosing algorithms
- Space complexity (memory usage) matters too - not just time
- Big O ignores constants - O(2n) and O(n) are both 'O(n)' in notation
Frequently Asked Questions
Why does Big O ignore constants?
Big O describes growth rate, not exact time. Constants matter for small inputs, but as inputs grow large, the dominant term matters most. O(1000n) and O(n) both scale linearly, so both are written as O(n). The 1000x difference is a constant factor.
When does O(n²) become a problem?
For 1,000 items, O(n²) = 1 million ops - usually fine. For 100,000 items, O(n²) = 10 billion ops - noticeable delay. For 1 million items, O(n²) = 1 trillion ops - takes minutes to hours. Use O(n log n) sorting instead of bubble sort for large data.
Is O(log n) basically constant?
Practically, yes! log₂(1 billion) ≈ 30, log₂(1 trillion) ≈ 40. So even for astronomical inputs, O(log n) operations stay tiny. This is why binary search on massive sorted arrays is nearly instant.
What about O(2^n)?
O(2^n) grows explosively. For n=30, that's 1 billion operations. For n=40, it's 1 trillion. These algorithms only work for tiny inputs (n < 20-30). Common in brute-force combinatorial problems like finding all subsets.
How do I determine my algorithm's Big O?
Count nested loops: 1 loop = O(n), 2 nested loops = O(n²), 3 nested = O(n³). Halving each iteration (like binary search) = O(log n). Sorting then processing often = O(n log n). Recursive calls with branching = often O(2^n) or O(n!).
Should I always use the most efficient algorithm?
Not always. An O(n²) algorithm might be simpler, easier to implement, and fast enough for your actual data size. Optimize when needed - premature optimization adds complexity for no real benefit. Profile first, optimize bottlenecks.