random.choices vs sample vs choice: Localhost Lab

Intro — what this post promises

Pick k items from a population via random.choices (with replacement), random.sample (without), and a loop of random.choice. This lab reports picks/s on Linux localhost.

Frame: with vs without replacement. It is not secrets/CSPRNG (lab 88) — random only, non-crypto.

Related links:

• secrets vs urandom localhost lab
• statistics quantiles vs manual localhost lab
• graphlib topo vs manual localhost lab
• functools cache vs lru localhost lab
• tomllib vs json localhost lab
• path glob vs fnmatch localhost lab
• dataclass replace vs manual localhost lab
• islice vs list slice localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. Affiliates: 0. random.Random(123) per process.

Verdict up front (pop=10 000, k=100): choices ~18900032 picks/s; choice loop ~4951720; sample ~4432033.

Arms

Lab topology

pop×k: 1k×10 · 1k×100 · 10k×100 · 10k×1k · 7 rounds · p50
metric: picks/s = k / p50_s

Script: lab-evidence/117-random-choices-vs-sample/results/run_lab.py.

Lead table — pop 10 k / k 100 (p50)

Scale sketch (picks/s)

With vs without replacement

choices may repeat indices; sample guarantees distinct elements. Product bugs often come from “shuffle-like” UX that silently allows duplicates. Write the invariant in the function name or type (UniqueDraw vs BootstrapDraw) before optimizing picks/s.

Weighted path cost

Equal weights still took the weighted implementation here (~489896 picks/s at 10k×100) — much slower than unweighted choices. If weights are uniform, omit them.

Reading it

• Duplicates OK → choices (faster than a Python choice loop here).
• Unique subset → sample (must use without-replacement semantics).
• Weighted draws → choices(..., weights=) (slower equal-weight path on this box).
• Tokens / keys / passwords → secrets, not random (lab 88).

API cheat sheet

Population size

sample cost grows with uniqueness bookkeeping; choices stays a tight with-replacement loop. At 10k×1k on this box, choices still led (~12228975 picks/s vs sample ~4517263). Re-measure if k approaches len(pop) — algorithms inside sample change character near that edge.

Determinism in tests

Seed with random.Random(seed) (as this lab did) or random.seed for reproducible unit tests. Do not confuse reproducible draws with cryptographic unpredictability — CI flakes from unseeded random are a test smell, not a reason to pull in secrets for shuffle fixtures.

Large k without replacement

When you need almost the whole population in random order, sample(pop, k=len(pop)) is a shuffle; for a full permutation random.shuffle on a copy may be clearer. Mid-sized k (as here) is where sample vs choices semantics dominate the API choice more than raw picks/s.

Pitfalls

• Using choices when uniqueness is required.
• sample with k > len(pop) (ValueError).
• Seeding random for security theater.
• Building huge weight arrays every call.

Reproduce

python3 lab-evidence/117-random-choices-vs-sample/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. Integer populations. Not NumPy RNG. Not crypto.

Takeaway

At pop=10 k / k=100, choices ~18900032 picks/s beat sample ~4432033 and a choice loop ~4951720. Match the API to replacement rules — never to secrets-grade needs.