Survey of Software Workshop Reports

Workshop · floor model

sortie

Sorting is solved. Choosing how to sort is not.

Sorting looks like the most settled problem in computing. Python has sorted(), it works, and most of the time that is the end of it. Underneath that one call sits a library choice, and the choice comes with conditions attached.

This page runs Python in your browser so you can watch those conditions decide the outcome. Every figure below is measured on your machine while you wait. Where a number came from research instead, it says so.

Sorting is worth the tour even if you never think about it, because the questions it asks come back at every scale. How much do you keep. How much do you throw away. What happens when work arrives faster than you can deal with it. Those are sorting questions at ten thousand items and infrastructure questions at ten million, and learning to read them in a small case is how you start recognising them in a large one.

Read the findings, run them yourself. Then switch to Play and see whether they stuck.

1. Re-sorting on every insert

A leaderboard has to stay in order while scores arrive one at a time. The obvious code appends the new score and sorts the list again.

The alternative never sorts. It finds where the score belongs and inserts it there, so the list is ordered the whole way through.

Both are correct. One does O(n² log n) work and the other O(n log n), so the gap widens as the data grows. That is why this passes code review on a small test and fails in production.

This one runs in JavaScript, so it starts instantly and downloads nothing. It is a fact about algorithms rather than about a language, so it holds anywhere.

Runs entirely in this tab. No download, a second or two.

The full version of this question — in Python, with four alternatives and your choice of size — is its own floor model: you want this sorted how?

2. Running the real libraries

The survey is about Python libraries, and no Python has run yet. This is real CPython in your browser — actual sorted(), numpy and sortedcontainers, compiled to WebAssembly.

Two comparisons run. The first sorts the same numbers two ways, sorted() against numpy.sort, which asks whether the library matters even when the algorithm is settled. The second repeats the leaderboard test above with SortedList doing the work, so you can watch that result hold in the language it was measured in.

It downloads 10–20 MB the first time, so it waits until you ask for it.

Nothing has been downloaded yet.
Why the tests stop here. Both comparisons above are sized to finish in a tab. The survey's largest benchmark is not: at 100 million rows it reports sorted() at roughly 30 seconds against about 2 seconds for polars, a ~15× gap. polars runs in this browser runtime; 100 million rows do not fit in one tab's memory budget.

That figure is cited from Survey of Software 1.001, not measured here — reproducing it needs native Python and real RAM. Which is the reason the research exists alongside the demo: a browser can show you the shape of a result, and then it runs out of room.

3. Now go build something

None of the above is your situation. You have a real one: a particular language, a particular shape of data, a particular thing that must not break.

Describe it below. The prompt assembles as you pick, and you take it to whichever assistant you already use. It asks for the conditions rather than a verdict, which is the habit worth keeping.

Language
How the data reaches you
What you need out
What is in it
What must not break

Assembled in this tab. Nothing is sent anywhere, and the page keeps no record of what you picked. The prompt asks your assistant for the conditions under which each option wins, and to say plainly when it is guessing.

What each library is for

These libraries do different kinds of sorting, so picking one is usually about a capability rather than a benchmark: whether the order has to hold between inserts, whether you want the permutation rather than the values, whether the data fits in memory at all.

sorted()Stable. Sorts anything comparable. key= takes any function. The right default, and the only one that needs no dependency.
numpy.sortkind= picks the algorithm — quicksort, mergesort, heapsort, stable. argsort returns the permutation instead of the data, which is what you want when sorting one array by another.
SortedContainersNot a faster sort — it never sorts. The collection is ordered at all times, so inserts are O(log n) and you get bisect and index access for free.
polarsMulti-column, lazy, and out-of-core. Sorts data larger than memory, which the others simply cannot do.
radix / countingNon-comparison sorts: O(n) for bounded integers, beating the O(n log n) floor by not comparing at all. Narrow, and unbeatable where they apply.

Why read the whole category

None of this says stop using sorted(). It says the default comes with conditions.

Knowing the category also does something beyond helping you pick. You cannot consider an architecture you do not know exists, so reading widely is how an option becomes available to you at all.

A survey gives you the conditions under which each option wins, rather than a winner. That is the difference between shopping at the hardware store and being able to work there.

Read Survey 1.001 — Advanced Sorting Libraries →

Field Notes — the surveys stay neutral; the Reports built from them argue a case, and a new one is at the center of each edition.

No tracking pixels. Unsubscribe in one click.