[In Development] Editing a Huge File Is Not About “Can You Open It” — It’s About How Many Times You Can Stop: 010 Editor, UltraEdit and UwEditor Pro on Mac ARM

This is a test log for a product still in development. UwEditor Pro is not for sale yet, and there is no release date.

When you work with a very large text file, “the editor can open it” is not the finish line.

Real work looks like this: you search for a string, replace it everywhere, fix a few things by hand, close the file for the day, and open it again tomorrow.

Open
→ search
→ replace all
→ hand edits
→ Close
× as many times as it takes
→ finally, produce the finished file

This time we compared three products running on Mac ARM.

• 010 Editor
• UltraEdit for Mac
• The in-development UwEditor Pro — Huge Files, No Rewriting (below, UEP)

The operations are the same for all three.

1. Open the file
2. Search the whole file for 東京 (Tokyo)
3. Replace 東京 with Tokyo everywhere
4. Quit part-way through the work
5. Next time, reopen the edit state
6. Finally, produce a normal text file

The short version

First open, and producing the finished text, were fast enough on the existing products.

The gaps appear in search, replace-all, and in stopping and resuming the work.

Note that the file sizes differ between the 010 Editor test and the UltraEdit test. The seconds in the two columns are not comparable with each other. Each product was paired against UEP on the same file.

Why the file sizes differ

The original plan was to compare all three products on the same ~50GB file.

010 Editor was too slow at 50GB to finish the full sequence in a practical amount of time, so the 010 Editor comparison uses a 10.19GB file.

UltraEdit displayed a message warning that files above 5GB would be slow, so the UltraEdit comparison uses a 3.07GB file.

This is not a benchmark that ranks the three products against each other.

It is a check of what happens when each product handles the largest file it can realistically work with, using a real editing sequence.

010 Editor

Test file

File: japan-dv-010-ab
Size: 10.19GB

Results

First open was essentially a tie. 010 Editor opened a 10GB file in about 11 seconds — that is fast.

Search and replace-all were 4.5–5.2x faster on UEP.

The larger gap is in saving. Writing normal text out of 010 Editor took 2 minutes 40 seconds. UEP produced the finished text in 12.3 seconds, or its compressed .uwvz in 5.8 seconds.

A possible misconfiguration on our side. That 2 min 40 s may reflect settings we did not tune. 010 Editor almost certainly has options that speed up processing and write-out, and we have not explored them. If you know which ones matter, please tell us — we will re-measure and correct this article by appending an update if the numbers change.

If you finish the edit in one sitting

Including the final text output:

010 Editor
11.0 + 11.5 + 16.3 + 160
= 198.8 s (about 3 min 19 s)

UwEditor Pro
10.9 + 2.2 + 3.6 + 12.3
= 29.0 s

Across the whole sequence, UEP was about 6.9x faster.

Counting the reopen after saving, 010 Editor is 211.1 s and UEP about 29 s — a gap of about 7.3x.

UltraEdit

Test file

File: japan-dv-UE3-af
Size: 3.07GB

Results

UltraEdit is fast at both opening and saving. Its final text write took 4 seconds against UEP’s 3.5 — no meaningful difference.

Search was about 5.6x apart, and replace-all about 10.8x.

The same caveat applies here. UltraEdit displayed a warning that files above 5GB would be slow — which suggests there are settings or modes intended for large files. Tuned properly, these numbers could change. If you know how, please tell us and we will re-test.

If you finish the edit in one sitting

UltraEdit
4.4 + 5.3 + 14.1 + 4.0
= 27.8 s

UwEditor Pro
3.54 + 0.94 + 1.31 + 3.5
= 9.29 s

Across the whole sequence, UEP was about 3x faster.

Counting the reopen after saving, UltraEdit is 33.8 s and UEP about 9.29 s — a gap of about 3.6x.

What “0 seconds to quit” actually means

UEP’s 0 seconds is not the time to produce a finished text file.

UEP does not rewrite the original data. Edits are recorded as a diff as you make them, so quitting part-way through does not require rewriting the whole huge file.

That makes the intended workflow look like this:

Day 1
Open → search, replace, fix → Close (0 s)

Day 2
Open (~0 s) → fix → Close (0 s)

Day 3
Open (~0 s) → fix → Close (0 s)

Final day
Produce the finished text, or the .uwvz

Closing part-way does not mean throwing the work away. It means the edit diff is already on disk, so there is nothing left to wait for.

The full file is written out only when you actually need the finished artifact.

The gap widens every time you stop

With 010 Editor, every interruption costs a 2-minute-40-second save, plus 12.3 seconds to reopen — about 172.3 seconds per stop-and-resume.

With UltraEdit it is 4 seconds to save and 6 to reopen — about 10 seconds.

With UEP, stopping and resuming is about 0 seconds.

The file sizes differ, so the 010 Editor and UltraEdit figures are not comparable with each other.

If a huge-file edit finishes in one sitting, the final save time is all that matters.

But when the work runs over several days — open, search, fix, stop — the save-and-reopen time accumulates. That repetition is what UEP is aimed at.

Being straight about the limits

These results are not an overall verdict on these products as text editors.

010 Editor is a powerful tool for far more than large text: binary data, disks, and structured file formats through templates.

UltraEdit brings years of accumulated features — programming support, regex, macros, project management.

On the range and maturity of editing features, both existing products are ahead of the in-development UEP.

UEP is narrow on purpose: editing a file too large for RAM, over many interrupted sessions.

Also note:

• The test files differ in size between the 010 Editor and UltraEdit runs
• Each product was compared against UEP on the same file
• Results vary with the Mac, RAM, SSD and OS cache state
• Regex, encoding and hit count all change the numbers
• The search term here is 東京; the replace is a plain string replace to Tokyo
• Neither 010 Editor nor UltraEdit was fully tuned — there may be settings we missed, and we will re-test if we learn of them
• UEP is in development and not for sale

Summary

010 Editor, UltraEdit and UEP all opened and edited multi-gigabyte files.

For first open, all three were practical. UltraEdit’s final text save is on par with UEP’s.

Where UEP was consistently faster: search and replace-all.

And the biggest difference is stopping and resuming.

010 Editor
Save the whole huge file → open it again next time

UltraEdit
Save quickly → open it again next time

UwEditor Pro
Close with the edit diff intact → resume instantly

For huge-file editing, what decides whether a tool is usable is not only “how many seconds faster is one operation,” but “how many times can I safely stop?”

UEP is not an editor for finishing a huge file in one pass.

It is an editor for work that is too big to finish in one pass, continued across days.

Related

If you only need to read huge files today, UwView Pro — Huge Files, No Waiting is the product that exists now.

• UwView Pro product page
• Editing a 48GB file on Windows and saving mid-way (vs EmEditor)
• Replacing 21,994 occurrences in a 100-million-line file in 16.8 s