Understanding algorithm visualisation
Step through the algorithm, watch the invariant.
Why visualising sort and search algorithms beats memorising big-O, what an invariant is, and the algorithms worth animating.
Why animation helps.
Algorithms are sequences of state mutations. Reading the code, you imagine the state changes; watching the animation, you see them. The moment you watch quicksort's partition step, or BFS expanding outward layer by layer, the asymptotic complexity stops being a memorised fact and starts being something obvious. The classic textbook analogy — "imagine the array as bars of different heights" — is exactly what these visualisers literalise.
Loop invariants.
An invariant is a property that's true before and after every iteration. Insertion sort's invariant: "the prefix arr[0..i] is sorted". Selection sort's invariant: "the suffix arr[i..n] contains the i largest values, already in place". Watching the animation makes the invariant visible; the sorted region grows, the unsorted shrinks. Once you can name the invariant, you can prove the algorithm correct without writing a line of formal logic.
The classic sort lineup.
Bubble (O(n²)): adjacent swaps, the largest "bubbles" to the end each pass. Insertion (O(n²) worst, O(n) on near-sorted): each element walks left into its sorted prefix. Selection (O(n²)): find the min of the unsorted region, swap to the front. Merge (O(n log n)): split in half, recursively sort, merge in linear time. Quick (O(n log n) average, O(n²) worst): pick a pivot, partition. Heap (O(n log n)): build a max-heap, repeatedly extract the max. Watching all six side by side on the same input is the one-image explanation of why O(n log n) matters.
A worked comparison.
Sort 100 random elements. Bubble: ~5,000 comparisons. Insertion: ~2,500 (much better on near-sorted input — try the visualiser with a "nearly sorted" preset). Merge: ~700. Quick (random pivots): ~660. The 7× advantage in comparison count is exactly what O(n log n) vs O(n²) means in practice — and at n = 1,000,000 it's the difference between 20 seconds and a week.
Sort 100 elements
O(n²) vs O(n log n)
Compare comparison counts at small and large n.
n=100: 5000 vs 700 ; n=10⁶: 5×10¹¹ vs 2×10⁷
= The gap widens with n
Search and graph algorithms.
BFS expands in concentric rings — shortest-path-by-edge-count becomes obvious. DFS dives along one path, backtracks. Dijkstra colours the visited region with cost increasing outward. A* shapes the visited region toward the goal because of the heuristic. Each animation reveals which inputs the algorithm thrives on and which inputs make it look bad. Worth running these against handcrafted adversarial inputs: DFS on a comb-shaped graph, Dijkstra on a sparse vs dense graph, A* with a bad heuristic.
Real-time vs step-mode.
Most visualisers offer two modes. Real-time runs at adjustable speed and gives a gestalt — "this looks roughly logarithmic" — that's hard to get from numbers. Step mode advances one operation at a time and lets you read the loop invariant at each state. Use both: real-time for shape, step mode for proof. Skipping step mode is the mistake — the comparison-counting and pointer-tracking happens there.