When you parallelize a text search, how many threads should you use? "One per core," "cores x 2," "physical cores only" — the folklore varies. The only number I trust is one measured on my own app, against real data.
I benchmarked the search engine of UwView Pro, my large-text viewer, against 0.89 billion lines of real data at 1-16 threads. The headline: it plateaus at 8 threads (3.0x over single-threaded) — on a 10-core machine.
The full methodology
- Machine: MacBook Air (Apple M4 / 10 cores = 4 performance + 6 efficiency / 32GB RAM / on AC power)
- Data: OpenStreetMap Japan
japan-latest.osm(48GB original, 0.89B lines) as a 5.3GB compressed.uwvzcache - Target: the search engine run standalone (
search-standalone) — no UI, no file-open cost - Condition: warm cache. Cold-cache numbers were not measured this time
- Protocol: a 1-to-16-thread sweep repeated for 4 rounds (round-robin), taking the per-thread-count median across rounds — 128 measurements total
Why round-robin instead of "measure 1, then 2, then 3..."? The M4 Air is fanless. Under sustained load it thermal-throttles, so measurement order leaks into the results as a systematic error: a sequential sweep measures the later thread counts on a hotter chip. That story deserved its own post (see the companion article); every number below is from the corrected protocol.
The harness is a single shell script driving the engine and dumping CSV; a Python script draws the plots.
Results
Two search patterns with very different hit counts:
| Threads | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tokyo (10,967 hits) |
22.2 | 13.8 | 11.5 | 10.2 | 9.2 | 8.6 | 7.8 | 7.4 | 7.4 | 7.4 | 7.8 | 8.0 | 7.9 | 7.9 | 7.6 | 7.5 |
Kamakura (722 hits) |
22.2 | 13.6 | 11.9 | 10.2 | 9.1 | 8.4 | 7.6 | 7.4 | 7.6 | 7.5 | 8.0 | 8.2 | 7.9 | 8.0 | 7.8 | 7.6 |
Three facts worth a headline
1. It plateaus at 8 threads: 22.2s single-threaded down to 7.4s (3.0x). From there to 16 threads it stays flat at 7.4-8.2s. More threads don't help — but notably, oversubscription up to 16 didn't visibly hurt either.
2. The plateau is not "the core count." This machine has 4 performance + 6 efficiency cores, 10 total. The plateau lands at 8 — short of all 10 cores, well past the 4 P-cores. Neither core type alone explains it. Apply the "threads = cores" folklore here and you'd pick 10 (same speed as 8, so no harm, no gain); pick 4 and you're at 10.2s — 27% slower.
3. Hit count doesn't matter. With hit counts differing by more than an order of magnitude (10,967 vs. 722), the two curves match almost perfectly. The work is dominated by how much you scan, not how much you find.
One finer observation: the scaling is sublinear from the start — 1.6x at 2 threads against an ideal 2x. The overhead and memory-bandwidth contention begin with the second thread, not the ninth.
Honest limitations
- All numbers are warm-cache; cold was not measured
- One machine only (MacBook Air M4); a CPU/RAM matrix is a separate planned experiment
- Nothing beyond 16 threads was measured
What this means for the product: automatic
What the data says: on this machine and workload, ~8 threads is the sweet spot, and missing it in either direction costs you. And the sweet spot will move from machine to machine. A "number of threads" setting in the UI would mostly be a device for users to pick the wrong value.
So UwView Pro chooses the thread count automatically (UWV_SHARDS=auto is the default). You configure nothing. This benchmark existed to decide what "auto" should do.
If you regularly search huge logs or datasets, give UwView Pro a look — persistent index, compressed-cache search, and ~1/9 storage make both reopening and searching a step faster (all OS, $129 one-time / $9 per month).
From the developer: a list of my apps, Kindle books and open-source projects is on GitHub: amru195704.
A note
The information in this article is provided for reference purposes only, and its accuracy or completeness is not guaranteed. If you notice any errors or inaccuracies, please let us know in the comments and we will review and correct them.
Top comments (0)