A Windows laptop with 16 GB of RAM, and a Mac (M4) with 32 GB. Files on an external USB SSD. On those two machines, with files many times larger than RAM, I have been measuring every tool that claims to handle gigantic text files since July 2026.
EmEditor, klogg, 010 Editor, UltraEdit, Log Viwer, grep, ripgrep, sed, amber. At 3 GB, 10 GB, 50 GB and 250 GB.
The short answer: yes, it works — but your options thin out as the file grows. And "it opens" turned out to be a different thing from "it's usable."
This article is a condensed version. Every number is on the full comparison page:
https://uvp.y42u.net/en/benchmarks-en/
Disclosure: I am the developer of one side of this comparison (UwView Pro). Please discount accordingly. The places where my own tool loses are left in.
Why "a modest laptop"?
On a workstation with plenty of RAM the file fits in memory, and most tools simply get faster. These numbers matter if you want to cope without buying a new machine.
The files (all single, unsplit files):
| Label | Content | Bytes | Lines |
|---|---|---|---|
| 3 GB | OpenStreetMap Japan, expanded to XML | 3,032,812,644 | 100 M |
| 10 GB | same | 10,255,315,281 | 100 M |
| 50 GB | same (also written as 48 GB) | 51,254,526,392 | 892 M |
| 250 GB | OpenStreetMap United States, as XML | 258,679,440,228 | 4.51 B |
Four steps were measured:
- Open — until the index is complete (the whole file usable), not time to first screen
- Search — two Japanese words, 東京 ("Tokyo") and 大阪 ("Osaka"); "New York" and others at 250 GB
- Replace — 東京 → Tokyo, and so on
- Save — until the write completes
How the grades work
Everything is a ratio (UwView Pro = 1.00; bigger is slower).
- Viewing grade — the geometric mean of the Open and Search ratios. Ratios live in a multiplicative world; an arithmetic mean would unfairly sink a tool that wins decisively on one of the two
- Editing grade — compared as repeated work: open → (search + replace) × 5 → save. Real editing means opening a file and fixing things several times
- CLI tools are separate — they have no "open", so the grade is CLI search time ÷ GUI (open + search), lining both up on total time until the answer appears
S (under 0.5×) / A (to 1.5×) / B (to 4×) / C (to 15×) / D (over 15×).
The conclusion, by size
| Size | The realistic choice |
|---|---|
| up to 3 GB | On Windows, EmEditor wins outright. Replace is 7× faster (0.14×), search more than twice as fast (0.45×), and repeated editing stretches to 0.39×. There is no reason to switch in this range |
| 10 GB | This is where it turns over. EmEditor holds its own on open and search, but save is 18.36×. 010 Editor's save is 27.84×. Yet 010 Editor is the faster one to open (0.73× on Windows) |
| 50 GB | For viewing, the other GUIs are still in the fight (opening is roughly level). Search is where they separate (010 Editor 5.02×, UltraEdit 7.33×, klogg 8.95×), and editing-and-saving is what decides it |
| 250 GB | Four GUIs opened and searched it: klogg, 010 Editor, UltraEdit and UwView. Exactly one got as far as editing and saving |
Five things that surprised me
1. At 3 GB, my own tool loses
| Step | EmEditor | UwView Pro + Edit | Ratio |
|---|---|---|---|
| Open | 5.0 s | 4.6 s | 1.09 |
| Search (2 words) | 1.06 s | 2.35 s | 0.45 |
| Replace (2×) | 0.9 s | 6.3 s | 0.14 |
| Save and close | 5.1 s | 3.2 s | 1.59 |
| Open + (search + replace) × 5 + save | 19.90 s | 51.05 s | 0.39 |
The 7× gap on replace is what decides it: by the third repetition the total has more than doubled. If you routinely edit files of around 3 GB on Windows, EmEditor is the better choice. For a small file, loading it into memory and rewriting it is simply quicker. The differential approach starts to pay from 10 GB.
2. "Opens fast" turned out to mean almost nothing
This was the biggest surprise at 250 GB. The tools that build no index open sooner.
| Tool | Open | Through 1 search | Through 5 searches |
|---|---|---|---|
| klogg | 4 min 18 s | 8 min 42 s | 26 min 18 s |
| 010 Editor | 4 min 45 s | 9 min 30 s | 28 min 32 s |
| UwView Pro | 5 min 18 s | 5 min 50 s | 8 min 00 s |
| ripgrep (reference) | — | 4 min 38 s | 23 min 10 s |
For klogg and 010 Editor, one search costs about as much as opening the file. Both are pinned to the physical floor (268.49 s for wc -l to read 258 GB once). In other words, every search reads all 258 GB again.
So by the end of the first search it has already reversed. The 317.8 s spent building an index is repaid by a single question. And at five questions both GUIs end up slower than ripgrep — a GUI taking longer than a command line.
3. Against the CLI, the real gap is 1.28–3.73×
Compare search alone and the CLI tools look 4–9× slower. But that compares only the search that happens after the index exists. The GUI built that index first. Line both up on total time until the answer appears:
| Size | UwView Pro (open + search) | ripgrep | GNU grep | amber | BSD grep |
|---|---|---|---|---|---|
| 3 GB | 4.945 s | 1.29× | 1.28× | 1.29× | 1.87× |
| 10 GB | 14.22 s | 1.53× | 1.53× | 1.48× | 1.56× |
| 50 GB | 81.3 s | 1.48× | 1.47× | 1.74× | 1.62× |
| 250 GB ※ | 479.7 s | 2.90× | 2.85× | 3.73× | 3.73× |
※ 250 GB alone is a five-question comparison.
4–9× shrinks to 1.28–3.73×. I think this is the most honest table in the whole set. If one or two questions are enough, a CLI tool will do. The index pays for itself when you ask the same file many questions.
Incidentally, the four CLI tools on identical data came out almost level:
| Tool | 3 GB | 10 GB | 50 GB |
|---|---|---|---|
GNU grep (ggrep) |
6.33 s | 21.72 s | 119.38 s |
| ripgrep | 6.39 s | 21.75 s | 120.70 s |
| amber | 6.37 s | 21.06 s | 141.50 s |
BSD grep (LC_ALL=C) |
9.25 s | 22.20 s | 131.48 s |
Effective throughput per pass explains why: everything flattens out around 950 MB/s. The ceiling is how fast the storage can be read, and a tool that reaches it cannot get any faster. Choosing a tool only matters for tools that have not reached that ceiling. The exceptions were BSD grep at 3 GB (656 MB/s, 1.46× slower than GNU grep) and amber at 50 GB (724 MB/s). If macOS's stock grep feels slow, installing GNU grep through Homebrew (it shows up as ggrep) is worth it.
4. The same application is a different tool on a different machine
I measured 010 Editor on both Windows and the Mac.
| Size | Operation | Windows (16 GB) | Mac (M4, 32 GB) |
|---|---|---|---|
| 3 GB | Open | 8.5 s | 6.78 s |
| 10 GB | Open | 21.5 s | 12.3 s |
| 50 GB | Open | 133.2 s | 56.7 s |
| 48–50 GB | Replace (1×) | abandoned at 20% | 12 min 45 s |
The bigger the file, the more the machine matters. At 3 GB the difference is 1.25×; opening 50 GB is 2.35×. And the 50 GB replace completed in 12 min 45 s on the Mac, while on Windows it was still at 20% after ten minutes.
I read that as a problem with rewriting 50 GB on 16 GB of RAM, not a problem with 010 Editor. On a machine with plenty of memory it may well go through on Windows too.
5. At 250 GB, more tools fall short than reach it
Four GUIs opened and searched the 250 GB file: klogg, 010 Editor, UltraEdit and UwView. Everything else could not be measured to the end under these conditions.
My own browser build did not get there either. It stalls at 51% of the load. Running in a browser has limits, and that territory belongs to the native build.
For several of the tools that fell short, I did work out why. But I have learned that stating another product's defect briefly is almost guaranteed to be inaccurate. Results changed when I changed the conditions, and in more than one case the cause turned out to be my own configuration.
So this article gives the results only. The causes — along with the corrections I had to publish when my own conclusions were wrong, and the exchanges with the developers — are in the full comparison, under "7. What 'could not measure' actually means".
What I did about "too fast to measure"
A stopwatch bottoms out at one second. Anything that reads "1 s" has not really been measured.
Recording it as one second can quietly flatter someone. It happened: 010 Editor's 3 GB save came out at "1 s". Writing 3.03 GB in one second means 3 GB per second — not a rate this external USB SSD can produce. In other words the operation returned before the write had flushed.
So I used the fastest write observed on the same machine and disk (877 MB/s) and set 3,032,812,644 bytes ÷ 877 MB/s = 3.5 s as a theoretical lower bound. No tool can write faster than that, so it is the most generous value available to the other side.
"Open" in these tables means the index is complete and the whole file is usable. Some tools show a window before they have read the file, and in those cases the reading simply moves into the first search — it is deferred, not avoided. How fast a window appears and how fast the whole file becomes usable are two different things.
Conversely, when a search came in under a second I counted it as one second, an upper bound. The real ratio is smaller. The rule is simple: never round in a direction that disadvantages the other tool.
Summary
A modest laptop can handle gigantic text files. But:
- At 3 GB nothing gives you trouble. On Windows, EmEditor is the best of them
- From 10 GB, saving starts to dominate
- At 50 GB most tools drop out. Viewing is still competitive; editing and saving is what decides it
- By 250 GB, four GUIs can still view the file
- If one or two questions are enough, a CLI tool will do. The index pays off when you ask the same file many questions
- The machine matters more as the file grows. The same application completes on one and, in my environment, did not finish on another
The full record — 4 sizes × 4 steps, what "could not measure" actually meant, the corrections I had to make when my own guesses turned out wrong, and the combinations I still have not measured — is here. The numbers where my own tool loses are all left in.
https://uvp.y42u.net/en/benchmarks-en/
There is also a companion piece that works out the CLI/GUI crossover point on the 258 GB file:
https://uvp.y42u.net/en/blog/uvp-258gb-cli-vs-gui-en/
Everything here was measured on my own machines. It may be a settings problem — if you know better, please tell me. I will verify and correct.
Correction (12 September 2026): Some of the tools originally covered (PilotEdit, lnav, Log Voyager) have been removed from the tables because they were not on comparable footing. The title has changed from 12 tools to 8, and statements about other vendors' products are now phrased as what I observed in my environment.
Top comments (0)