Big-O: describe growth, not microseconds

Big-O notation answers: “If I double the training set / feature dimension / graph size, what happens to runtime in the limit?” It deliberately hides constant factors and hardware details—those still matter for a 10× speedup on a fixed workload, but they do not tell you whether an algorithm survives a move from 10⁴ to 10⁸ rows.

In data science you routinely contrast O(n) scans, O(n log n) sorts and divide-and-conquer routines, O(n²) naive all-pairs or nested-loop feature interactions, and worse. Best, average, and worst cases differ: quicksort’s average behaviour is not its worst case; adversarial inputs exist for many textbook algorithms.

Asymptotics pair with empirical profiling: a “fast” O(n²) on small n can beat a heavy O(n log n) with giant constants until n crosses over. Use Big-O to reason about scaling; use timers and profilers to choose implementations at the sizes you actually run.

Complexity cheat sheet (educational): [1].