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. I raced it against my own tool — UwView Pro with its Edit Upgrade (UVP+Edit below) — on the same laptop, same job: open → 2 literal replacements (東京→Tokyo, 大阪→Osaka) → save & close.
One caveat up front, and it matters: the machine was a Windows laptop with 16 GB of RAM. Working on a 50 GB file with 16 GB of memory is an unusual setup — almost nobody does this on purpose. That's exactly the situation I wanted to measure. And full disclosure: I'm the developer of UwView, so discount accordingly.
One full cycle
| Data | Step | EmEditor | UVP+Edit |
|---|---|---|---|
| 3 GB / 100M lines | Open | 5.0 s | 4.6 s |
| Replace ×2 | 0.9 s | 6.3 s | |
| Save & close | 5.1 s | 3.2 s | |
| Total | 11.0 s | 14.1 s | |
| 10 GB / 100M lines | Open | 14.0 s | 29.3 s |
| Replace ×2 | 28.6 s | 12.41 s | |
| Save & close | 187.3 s | 10.2 s | |
| Total | 229.9 s | 51.91 s | |
| 50 GB / 892M lines | Open | 301.1 s | 76.1 s |
| Replace ×2 | 11 min 12 s (371.1 s + 301.1 s*) | 47.0 s | |
| Save & close | 31 min | 49.9 s | |
| Total | 47 min 13 s | 2 min 53 s |
* The 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.
Beaten, reversed, cliff
At 3 GB, my product lost outright — replace alone 0.9 s vs 6.3 s, total 11.0 s vs 14.1 s. When the file fits in RAM, EmEditor's replace engine is simply fast.
At 10 GB the totals flip (that 187-second save & close). At 50 GB it's not a reversal but a cliff: 47 minutes 13 seconds vs 2 minutes 53 seconds — and that's with the hung attempt excluded.
The boundary is almost certainly the 16 GB of RAM. An editor that flies while the file fits in memory drops into swap-and-disk-I/O territory the moment it doesn't (my outside reading — I haven't audited EmEditor's internals). UVP+Edit never loads the file into memory at all (index + non-destructive edits), so nothing changes for it at 50 GB.
In EmEditor's defense
This result belongs to one specific, unusual condition. People who handle 50 GB files daily use workstations with 64–128 GB of RAM, and with ample memory these results may well look different. EmEditor is a veteran, widely trusted editor, its replace engine is the real thing, and this article does not dispute its published large-file limits. The narrow question I measured: what happens when a 50 GB log lands on the everyday 16 GB laptop you actually have in front of you — which, during incidents, is a thing that happens.
The five-day projection
Same two replacements as a daily job, five days: at 3 GB the totals nearly tie (55.0 s vs 39.3 s), at 10 GB it's ~11.3× (19 min vs 1 min 42 s), at 50 GB it's ~3 h 56 min vs 6 min 01 s (~39.2×). Mechanism note: both tools open and close every day — UVP+Edit does not stay open. On close it writes its edit state to a small sidecar file (.ewvz) and reads it back on the next open, never rewriting the 50 GB original, so its close/open from day two onward is near-zero (the projection charges day one's open and day five's close at full cost). EmEditor rewrites the file on every save, so each day pays full price. A design difference, not a work-habit difference.
Full disclosure
- One machine, one file family, two literal replacements. Complex edits or regex could land differently
- The 50 GB second replacement is a re-measured value: the first attempt hung at 13 min, so I rebooted and ran it again (the hung attempt's time is not counted)
- The vendor measured his own product. Rerun it and tell me — I'll update the article to match
UwView Pro is on sale (Windows, macOS, Linux — one license covers all three; 14-day free trial — editing features included). Full tables, conditions, and the five-day math are in the original article:
https://uvp.y42u.net/en/blog/uvp-edit-emeditor-16gb-notebook-en/
Top comments (0)