“Find a specific string in this 48 GB file.”
When you get that request, what matters is not just “does the software support 48 GB?” It’s:
- Can you jump to the end of the file right after opening it?
- How many minutes does a full-text search take?
- When you open the same file again tomorrow, do you wait again?
In real work with huge files, the problem is rarely the maximum supported size. It’s the waiting time before you can start working.
This article compares EmEditor Professional and UwView Pro on the same Windows laptop, using a single ~48 GB, ~892-million-line OpenStreetMap Japan file.
- The conclusion first
- Test environment
- Results
- Problem 1: it opens, but you can’t reach the end
- Problem 2: waiting for full-text search
- Problem 3: the same file makes you wait again next time
- From index to search completion
- EmEditor’s strengths
- UwView competes on waiting time, not feature count
- 48 GB is not the ceiling
- Next concept: a huge-file editor that never touches the original
- Summary
- Links
The conclusion first
In this environment:
- EmEditor could move across the whole file after about 4 min 06 s
- UwView Pro could jump to the end immediately after opening
- Index building was about 3.3× faster in UwView Pro
- A full-text search for “東京” (Tokyo) was about 12.8× faster in UwView Pro
- EmEditor needed the ~4-minute pass again on the second open
- UwView Pro reopened instantly from its saved index
On the other hand, EmEditor is overwhelmingly richer in editing features.
This comparison does not decide “which is the better editor”. It measures what difference appears in the time before real viewing-and-searching work can begin on a huge file.
Test environment
| Item | Details |
|---|---|
| PC | HP Spectre x360 |
| OS | Windows 11 Home (x64) |
| CPU | Intel Core i7-1165G7 2.80GHz |
| RAM | 16 GB |
| Storage | Internal SSD |
| Power | AC connected |
| EmEditor | Professional 64-bit v26.2.5 |
| UwView Pro | v1.2.2 x64 |
| Test data | OpenStreetMap Japan |
| File size | ~48 GB |
| Lines | ~892 million |
| Encoding | UTF-8 |
| Search string | “東京” (Tokyo) |
Both products ran on the same PC, the same internal SSD, and the same file. Both were native x64 builds on an Intel Windows machine, so no CPU-architecture emulation is involved.
Results
| Task | EmEditor Professional 26.2.5 | UwView Pro 1.2.2 |
|---|---|---|
| Display right after opening | Shows the beginning | Shows the beginning |
| Jump to the end right after opening | Not possible | Possible |
| Whole file navigable after | 4 min 06 s | Immediately |
| Index building completed | 246 s | 74 s |
| Full-text search for “東京” | 160 s | 12.5 s |
| Reopening the same file | ~4 min again | No re-indexing — instant |
Problem 1: it opens, but you can’t reach the end
EmEditor started displaying the beginning of the 48 GB file promptly.
However, until the loading progress reached 100%, it could not move to the end of the file. At the start of measurement, 18,951 lines were viewable — out of roughly 892 million.
The progress advanced like this:
- 1 min 14 s: 29%
- 2 min 35 s: 50%
- 4 min 06 s: 100%
Only after 4 minutes 06 seconds could the end of the file be reached.
UwView Pro also builds its index in the background. But the whole file is viewable before the index completes: jump to the end, check the 50% mark, start searching — immediately after opening.
The difference is not “time until display starts”. It is “time until you can reach what you’re investigating”.
Problem 2: waiting for full-text search
Searching the same 48 GB file for “東京”:
- EmEditor: 2 min 40 s
- UwView Pro: 12.5 s
Under these conditions, UwView Pro was about 12.8× faster — a difference of about 2 min 28 s per search.
Once is a few minutes. But in an incident investigation you search repeatedly with different terms. Ten searches means, by simple arithmetic, about 24 minutes of difference.
Problem 3: the same file makes you wait again next time
Opening the same file a second time in EmEditor required the ~4-minute pass again.
UwView Pro saves the index and compressed cache built on the first open, so from the second time on it opens almost instantly without re-indexing.
The gap grows in work like this:
- an incident log investigated over several days
- audit logs checked repeatedly
- chasing a cause while changing search terms
- the same map / observation / dump data referenced again and again
UwView Pro’s central value is not being fast once. It is removing the waiting time that recurs every time you use the same huge file.
From index to search completion
Treating it as one job — build the index, then search — the simple totals are:
EmEditor: full load 246 s + search 160 s = 406 s, about 6 min 46 s
UwView Pro: index 74 s + search 12.5 s = 86.5 s, about 1 min 27 s
A difference of about 5 min 20 s; UwView Pro was about 4.7× faster. And since UwView Pro lets you browse the whole file before indexing finishes, in practice you don’t even wait the 74 seconds to start investigating.
EmEditor’s strengths
EmEditor is an exceptionally capable commercial text editor for Windows: CSV editing, sorting, replace, macros, and an enormous accumulation of editing features built over many years.
Officially, the 64-bit edition opens files up to 16 TB or about 1.099 trillion lines, and a Large File Controller is provided for opening a specified portion of files beyond that. See EmEditor’s official Large File Support page.
If you need advanced editing, CSV processing, macros, or automation, there are plenty of reasons to choose EmEditor. It is not realistic for UwView to compete on feature count.
UwView competes on waiting time, not feature count
UwView does not aim to be a general-purpose text editor. It specializes in these tasks on huge files:
- view the whole file the moment it opens
- move to the end or any position
- search huge files fast
- open the same file instantly from the second time on
- archive compressed, and re-investigate without unpacking
For a one-time look at a huge file, the free edition of UwView is enough. For repeated opens, fast search, and compressed archiving, UwView Pro is the fit.
48 GB is not the ceiling
The 48 GB file was one test case, chosen so both products faced identical conditions.
Separately, UwView’s huge-file engine has been verified up to about 250 GB and 4.5 billion lines.
The design limit under the current block settings is about 550 billion lines. The block constant can be raised further, but in reality, the storage needed to hold such a file becomes the constraint first.
Three numbers worth keeping distinct:
- ~48 GB / 892 million lines: this comparison
- ~250 GB / 4.5 billion lines: largest verified measurement
- ~550 billion lines: theoretical limit under current settings
Rather than saying “unlimited”, we publish measured values and theoretical values separately.
Next concept: a huge-file editor that never touches the original
We are planning an editing edition built on UwView’s huge-file engine: UwView Editor Pro (working name, UEP).
UEP saves differently from ordinary text editors:
The original file is never modified.
Edits are stored inside a compressed file, and a new text file is written out only when you need one. UEP does not aim to be “an editor that overwrites huge files in place” — it aims to be
an editor that keeps the huge original intact and applies non-destructive corrections only where needed.
Intended work: fixing one wrong line in 48 GB of data; correcting observation / map / log data without altering the source; trying multiple candidate fixes; saving the edits and resuming later; producing a new text file only when the final output is needed. Because the original always remains, there is no risk of losing it to an editing mistake or a failed save.
UEP’s performance is expected to stay within about a 1.1× slowdown from UVP — but this is a design estimate at this point. At release, we will measure and report editing, saving, reopening, and text export.
Summary
On this 48 GB, ~892-million-line file:
- UwView Pro could browse the whole file immediately after opening
- index building was about 3.3× faster than EmEditor
- full-text search was about 12.8× faster
- reopening was instant, with no re-indexing
Meanwhile, EmEditor is far richer in editing features. So the choice is clear:
- rich editing, CSV, macros: EmEditor
- view and search huge files right away: UwView
- investigate the same huge files repeatedly, fast: UwView Pro
- non-destructive editing of huge data without touching the original: the future UEP
With huge files, what matters is not only “can it open the file eventually” but “how many minutes after opening can you start working”. UwView specializes in shrinking that waiting time.
Links
- UwView free edition (GitHub)
- UwView Pro product page
- Measured comparison with klogg (47.73 GB, reopen, search)
UwView Pro offers a one-time purchase and a monthly plan. The monthly plan includes a one-month free period via the payment service Polar.
From the developer: My apps, Kindle books, and open-source projects are listed at GitHub: amru195704.
About these measurements
The results in this article are measurements on the one PC, one file, and the product versions listed. They do not guarantee performance in every environment. Results vary with storage, CPU, memory, file content, encoding, search conditions, and product settings — please verify with your own environment and data. EmEditor is a product of Emurasoft, Inc. If you find an error, please point it out in the comments and it will be corrected after verification.
