Big O notation

I just figured out a simple way to understand BigO notation, aka the algorithm complexity numbers.

Let's say you have your myFn function and inside it you have some logic (an algorithm) that takes some inputs (n elements).

One concept you need to understand is that a machine can roughly do ~10⁹ operations per second.

An operation can be a comparison, an addition, an arr[i], an i++. So if you want to check for yourself, paste this code in your browser console:

const myFn = (n) => {
  let i = 0
  while (i < n) {
    i++
  }
}

const myCalls = 1_000_000_000 // billion, with a "B" or 10⁹

const s = performance.now();
myFn(myCalls);
console.log(`run ${(performance.now() - s).toFixed(0)} ms`);
run 956 ms // roughly 1 second

As you see, it's a run 956 ms. Careful though — this number is not stable: run it a few times, or on a different machine, and you'll get anywhere from ~250ms to ~1.1s for the exact same code. It depends on your machine's state (other tabs, memory pressure) and how aggressively the engine optimises the loop.
Also note, this is just an example to give you a feel of what an "operation", which in this case is i++.

And now, the fun part. The above loop is O(n) — it does one operation per element, so n operations in total. And since the machine does ~10⁹ operations per second, the most it can get through in one second is about 10⁹ elements.

So if you do myFn(5 * myCalls) — that's 5× the operations — it takes roughly 5× as long. That's exactly what linear (O(n)) means. Don't count on an exact number though: the wall-clock swings a lot with your machine and environment (on native Node it's ~2s; a browser-based playground running Node in WebAssembly can be 5s+). The shape is the point — 5× the work, ~5× the time.

And here is why algorithm complexity matters. It basically answers you this question:

For a given complexity, how many items can this algorithm process in one second?

or if you want it more academic sounding

Given a rough computation budget, how large can n get for an algorithm of this complexity?

Bigger complexity means fewer items. Which also means, depending on how big your n is, it can take from a few ms to hours to process.

Here is a table which tells you how many n elements can your algorithm process in 1 second with ~10⁹ simple operations as our one-second budget.

Complexity	Name	Max n in ~1s (ballpark)
O(1)	constant	unbounded
O(log n)	logarithmic	astronomically large
O(√n)	root	~10¹⁸
O(n)	linear	~10⁹
O(n log n)	linearithmic	~10⁷
O(n²)	quadratic	~10⁴–10⁵
O(n³)	cubic	~10³
O(2ⁿ)	exponential	~30
O(n!)	factorial	~12

Note that these numbers are an approximation, not fixed numbers, but it's a starting point that can help you better visualize what these complexities are all about.

Let me know if it clicked for you as it clicked for me.