The UwView Window Caught Up With uvf … -open — 50 GB End to End, From 189.5 s to 53.7 s

[Correction, 21 Sept 2026] When this went up, the uvf … -open figure we compared against, 53.69 s, was the v1.6.5 value. It now uses the v1.6.6 value (50.76 s), the same version as the window. Accordingly the claim “0.01 s apart” has become “about 3 s apart”. Both the window and the command now open and search at the same time, so the remaining 3 s or so is drawing the window, plus the steps of opening the file and typing the term.

Yesterday we published our own weak spot. It was the most painful line in an honest re-measurement against klogg.

The free GUI opens at 486 MB/s. klogg opens at 930 MB/s. Very nearly a factor of two.
(…) klogg saturating the medium is, for us, a measured target. We will close it in a coming release.
— We Lose to klogg on Opening. uvf Wins the Whole Run (2026-09-18)

The coming release came, and we closed it.

The result

One 51.25 GB file. Stopwatch, from the moment you open the file to a line-numbered list of hits on screen.

53.7 s. 51.25 GB ÷ 53.7 s = 910 MB/s — this drive’s raw read speed.

The command, uvf … -open on v1.6.6, takes 50.76 s — about 3 s less than the window. Both read the file only once, so what is left is drawing the window, and the steps of opening the file and typing the term.

One more thing worth pointing at. 3.53× and 2.01× are the exact ratios the v1.6.5 uvf … -open posted in yesterday’s article.
Which is to say — the window caught up with the previous version of the command. And the command itself moved on in v1.6.6, from 53.69 s to 50.76 s.

What changed

One thing. The search can now start without waiting for the index to finish.

Through v1.6.5 the window worked like this:

1. Open the file; build the index in the background (100.6 s at 50 GB)
2. Once the index is done, search (88.9 s)
3. Total: 189.50 s

The problem was reading it twice. Step 1 reads everything; step 2 reads everything again. klogg is built the same way,
which is why klogg takes 108.14 s. Meanwhile uvf … -open searches, builds the index and hands it to the window
during a single read — hence 53.69 s even on v1.6.5 (50.76 s on v1.6.6).

v1.6.6 gives the window the same shape. Because you can search while it is still opening, the file is read once.
It nearly matches uvf … -open because it now does the same thing.

For the record, here is what we predicted yesterday:

If the GUI’s index build is brought to the same way of reading, opening 50 GB should go from 100.6 s to somewhere near 52 s.

We were wrong. What came in around 52 s was not the open — it was open plus search plus putting it on screen.

We are not publishing seconds for 3 GB or 10 GB

Honestly: 3 GB and 10 GB are past what we can resolve by hand.

At 3 GB it cannot be measured at all. The file finishes opening while you are still typing the search term.
The “wait, then search” step is gone, so there is no waiting left to time.

10 GB is much the same — not a range where a human with a stopwatch should be arguing about seconds.
Putting a number on something you cannot measure is not a measurement, it is a sentence. So we are not doing it.

What we can say is this: opening and searching run at the same time, and at 3 GB the file is open before you start looking.

Where the honest lines are

[Added 2026-09-19] We measured “just opening” too. It is now faster than klogg at all three sizes.

As throughput that is 967 / 966 / 969 MB/s — the same figure at all three sizes, which is the speed of the medium
itself (3 GB fits in RAM and still reads at 967, so this is not a cached number). 1.99× the old 486 MB/s — very nearly double.

And one more thing. Opening 50 GB takes 50.44 s; the end-to-end run in this article takes 53.7 s — 3.3 s apart.
The search runs while the file is being opened, so once the read is done only the tail of the search remains.

When this article went up we said we would not claim it without measuring. We measured it, so here it is.

klogg remains an excellent tool. Free, open source, and fast to open. All this article shows is one thing:
run through to reading the hits and ours is shorter. Different jobs, different answers.

Nothing changes about Pro (uvp) either. What got faster is the free edition’s first question.
Ask the same file a second and third question and Pro, with its .uwvz, is in another class — 6.34 s to search 50 GB,
0.01–0.07 s to open it again. Looking once: the free edition is enough. Coming back: Pro.

How it was measured

• File: OpenStreetMap Japan XML, one file of 51,254,526,392 bytes
• Term: 東京 (94,979 hits)
• Cold, after sudo purge. One stopwatch, from opening the file to a line-numbered list of hits on screen
• Mac M4 / 32 GB / external USB SSD (about 950 MB/s raw), UwView free GUI v1.6.6
• The 189.50 s and 108.14 s comparisons are measurements from yesterday’s article — same machine, same file, same conditions. uvf … -open‘s 50.76 s is measured on v1.6.6 (cold, after sudo purge)

Both uvf and the free GUI are free, as a single download from GitHub Releases.
If you want an index kept so you can come back to the same file, that is UwView Pro.