Losing at 3 GB, a Cliff at 50 GB — EmEditor vs UwView Pro + Edit Upgrade on a 16 GB-RAM Laptop

Let me lead with the loss. On raw replace speed, EmEditor was 7.0× faster than my product.

EmEditor is the classic Windows editor for huge files (its published limit goes up to 16 TB). I raced it against the editing option of my own viewer, UwView Pro — the Edit Upgrade (hereafter UVP+Edit) — on the same laptop, running the same job: open → 2 replacements → save & close.

Test conditions

• Machine: a Windows laptop with 16 GB of RAM (same machine, same files)
• Job: open the file → replace twice (東京→Tokyo, 大阪→Osaka) → save and close, as one cycle
• I am the developer of UwView. The vendor is doing the measuring — discount accordingly

And one caveat before anything else: working on a 50 GB file with a 16 GB laptop is itself an unusual setup. More on that below.

Result 1: one full cycle

* At 50 GB, EmEditor’s second replacement hung on the first attempt — still unfinished after 13 minutes — so I rebooted the PC and re-ran it; 301.1 s is the re-measured value. The hung attempt’s time is not counted in the total. On the two replacements combined, 672.2 s vs 47.0 s puts UVP+Edit about 14.3× faster.

Beaten at 3 GB, reversed at 10 GB, a cliff at 50 GB

At 3 GB, UVP+Edit lost outright. Replace alone was 0.9 s vs 6.3 s — EmEditor 7.0× faster — and EmEditor also won the total, 11.0 s to 14.1 s. When the file fits in RAM, EmEditor’s replace engine is fast. I say that without reservation.

At 10 GB things shift. EmEditor opens and replaces respectably, but “save & close” takes 187.3 s, and the totals flip: 229.9 s vs 51.91 s.

At 50 GB it is not a reversal but a cliff. EmEditor needed 5 minutes to open and 6 minutes for the first replacement; the second replacement hung — unfinished after 13 minutes — so I rebooted and re-measured it at 301.1 s; saving and closing took 31 minutes — 47 minutes 13 seconds total. UVP+Edit finished the same job in 2 minutes 53 seconds.

The boundary is almost certainly the 16 GB of RAM. An editor that flies while the file fits in memory drops into the world of swapping and disk I/O the moment it doesn’t — that is my outside reading; I have not audited EmEditor’s internals. UVP+Edit never loads the file into memory in the first place (index + non-destructive edits), so its behavior simply doesn’t change at 50 GB.

In EmEditor’s defense — this is an unusual test

I want to stress that this result belongs to one specific condition: a 16 GB laptop.

• Almost nobody works on 50 GB logs with a 16 GB laptop. People who handle files that size daily use desktops or workstations with 64–128 GB of RAM, and with ample memory these results may well look different
• EmEditor’s replace engine is the real thing. Within RAM (3 GB here), it beat UVP+Edit on the replace by 7.0× and on the total
• EmEditor is a veteran, widely trusted editor, and this article does not dispute its published large-file limits. What I measured is the narrower question: what happens when a 50 GB file lands on a machine that only has 16 GB

That said, this unusual situation does happen in the field. When an incident dumps another system’s logs on you, the machine at hand is your everyday laptop. Read this as a benchmark for that moment.

Result 2: the same job for five days

I also projected the same two replacements as a daily job over five days.

How this actually works. Both tools open, work, and close every day — UVP+Edit does not stay open. When it closes, it writes the edit state out to a small sidecar file (.ewvz); the next day it reads that file back and reopens. Because the 50 GB original is never rewritten, the close/open from day two onward is near-zero — the projection charges only day one’s open and day five’s close at full measured cost. EmEditor, by contrast, writes the file itself out on every save, so each day pays the full open/close price. That is a design difference, not a difference in work habits.

Full disclosure

• One machine, one file family, and a deliberately simple job (two literal replacements). Complex edits, macros, or regex replacements could land differently
• EmEditor’s second replacement at 50 GB is a re-measured value (301.1 s): the first attempt hung, still unfinished after 13 minutes, so I rebooted the PC and ran it again. The hung attempt’s time is not counted
• The “why it slows down” paragraph is inference, not an audit of EmEditor’s internals
• The vendor measured his own product. If you rerun this under the same conditions, let me know — I will update the article to match

The tool used

UwView Pro is on sale (Windows, macOS, Linux — one license covers all three; one-time or monthly, with a 14-day free trial — editing features included). Non-destructive editing of huge files comes with the Edit Upgrade. For a one-off look, the free UwView is enough.

Links

• Replacing 21,994 Matches in a 10 GB, 100-Million-Line File in 16.8 Seconds — the Edit Upgrade’s replace benchmark
• Is ripgrep Really the Fastest on a 51 GB Single File? — CLI search on the same file family
• Does ‘Opens 100 GB in Your Browser’ Hold Up? — the Log Voyager comparison
• An Honest Comparison with klogg [Ver1.1.1, Complete Edition]

From the developer: a list of my apps, Kindle books and public projects is on GitHub: amru195704.

A note
The information in this article is provided for reference purposes only, and we do not guarantee its accuracy or completeness. All measurements reflect the specific environment described above and may differ on other hardware. If you notice any errors or inaccuracies, please let us know in the comments and we will review and correct them.