Since July 2026 I have been measuring, on real machines, every tool that claims to handle gigantic text files. This page is the whole record condensed into one approximate comparison table.
Everything is expressed as a ratio against UwView Pro (viewing) / UwView Pro + Edit Upgrade (editing) = 1.00. Bigger means slower; below 1.00 means faster than UwView Pro.
★ This is an at-a-glance approximation, not a controlled benchmark
Numbers measured at different times, on different operating systems and different storage are placed in the same table (a 16 GB Windows laptop and a 32 GB Mac M4; a USB HDD at 0.10 GB/s and an internal SSD at 3.29 GB/s).
It is not a strict comparison. Use it to get the order of magnitude and the trend.
The exact conditions behind every cell are written up in the linked articles below.★ The scenario is “open a gigantic file on the laptop you already own”
The machines were a Windows laptop with 16 GB of RAM (files on its internal SSD) and a Mac (M4) with 32 GB (files on an external USB SSD / HDD). The files are many times larger than RAM — the point of these measurements is to see how far that stays practical. Because the storage differs between the two machines, seconds cannot be compared across operating systems — ratios are only ever computed within one machine.
On a workstation with plenty of RAM, or with everything on fast internal storage, the results change a lot. Once a file fits in memory most tools simply get faster, and something marked “could not measure” here may well run perfectly.
Put the other way round: this table matters if you want to cope without buying a new machine. Please read the numbers with that premise in mind.
- Overview — Grades by OS and file size
- How to read the detailed tables
- Conclusions — what to use at each size
- 1. Open — until the index is complete (the whole file usable)
- 2. Search
- Four CLI tools on Japanese data: almost identical (14 September 2026)
- But that 4–9× is “after the index exists”
- 250 GB — four GUIs opened it, one got as far as editing (re-measured 14 September 2026)
- UltraEdit — opens up to 50 GB, does not open 250 GB (14 September 2026)
- 010 Editor / Log Viewer vs UwView Pro + Edit — measured side by side on the Mac (14 September 2026)
- 010 Editor measured on Windows too — the same tool on two machines (14 September 2026)
- klogg measured on Windows too — an A at 10 GB (14 September 2026)
- About the UltraEdit Windows measurements
- EmEditor vs UwView Pro + Edit — measured side by side on Windows (14 September 2026)
- Why “open” from that run is not used
- 3. Replace (editors only)
- 4. Save (editors only, measured as a .uwvz write)
- 5. Whole-job totals — “open it, find it, fix it, save it”
- 6. Combinations not yet measured
- 7. What “could not measure” actually means
- Related articles — the exact conditions behind every cell
- Try it — start in the browser
Overview — Grades by OS and file size
If you only look at three tables, look at these. Every individual number is further down.
| Grade | Meaning (ratio to UwView Pro = 1.00) |
|---|---|
| S | under 0.5× — more than twice as fast as UwView Pro |
| A | 0.5–1.5× — effectively equal (UwView Pro is the baseline, so it is always A) |
| B | 1.5–4× |
| C | 4–15× |
| D | over 15× |
| F | only one of the two steps produced a number (Open and Search for viewing; Replace and Save for editing). The other was not measured, or did not finish. It means the combined figure cannot be computed — it is not a verdict on speed |
| OK | confirmed to work, but no measurement at that size (includes downward inference from a larger size that did work) |
| × | could not measure (did not finish / conditions could not be met). If a smaller size could not be measured, every larger size is also × |
| — | not measured |
How the grades are decided (mechanically — there is no discretionary bonus)
- Viewing grade … the geometric mean of the Open ratio and the Search ratio. Ratios live in a multiplicative world; an arithmetic mean would unfairly sink a tool that wins decisively on one of the two. If only one of the two was measured, the grade is F (nothing to compare — it does not mean “slow”)
- CLI tools are handled separately … they have no “open”, so the grade is the CLI search time ÷ UwView Pro’s (open + search). That puts both on total time until you have the answer
- Editing grade … compared as repeated work: open → (search + replace) × 5 → save. Real editing means “open it and fix things several times”, so this is closer to reality than a single pass
- Only tools actually measured on that OS are listed. Numbers from another OS are never carried over into a table
- D, F and × mean different things. D is “measured, and it came out more than 15× slower.” F is “one value is missing, so no combined figure” — the other value does exist, which also means it works that far. × is “not usable at that size.” If you see an F, it is not a mark against the tool; it means I do not have enough to judge
Windows
On the Windows machine (16 GB laptop) I measured four: EmEditor, 010 Editor, klogg and the UwView family. UltraEdit was measured too, but removed because the large-file settings had not been adjusted.
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro (viewing) | A | A | A | — |
| EmEditor | A | A | C | — |
| 010 Editor | B | B | B | — |
| klogg (viewer only) | B | A | B | — |
※ The 250 GB column is “—” because I have not been able to put a 250 GB file on the Windows machine. UwView Pro itself — the baseline — has not been measured there, so nothing else can be compared either. Every 250 GB number on this page comes from the Mac (see the macOS table). PilotEdit has been removed from this table (see the note above).
※ The Windows measurements for 010 Editor were added on 14 September 2026. It is a steady B at all three sizes. At 10 GB it opens at 0.73× — faster than UwView Pro (21.5 s vs 29.3 s) — while search is 4.78×. The pattern from the Mac (fast to open, falls behind on search) shows up unchanged.
※ klogg was also measured on Windows on 14 September 2026. 10 GB is an A — open at 0.53× (15.5 s vs 29.3 s), half of UwView Pro, with search held to 3.98×. That 0.53× however is computed against a UwView Pro 10 GB open of 29.3 s. A separate run on the same day produced 8.11 s, which would make it 1.91× and a grade of B. That run was discarded as a pair because EmEditor’s side of it was anomalous, so I am not using it — but the decision happens to favour klogg (details in the note under “1. Open”).
※ UltraEdit has been removed from the Windows table. The measurements were taken without adjusting the large-file settings. The Mac measurements stand.
※ PilotEdit has been removed from this table (12 September 2026). In my environment, Find All ends the application, so I could not measure search at all (plain Find works). I asked the vendor, who cannot reproduce it and sent video to show it, so this is most likely specific to my machine. I am working out the cause and will re-measure and restore the rows once I know.
| File tried | Search term | Result in my environment |
|---|---|---|
| ~2 KB of Japanese text | 東京 | could not search (application ended) |
| ~4 KB, ASCII only (a licence document) | you | same |
| the same file | UwView | same |
| 3 GB | 東京 | same (14 September 2026) |
※ Opening works — open alone is 3.35× / 1.50× / 3.57×, which is not slow at all. This may well be a problem with my environment or settings. If search works for you, I would like to hear how.
Editing (the whole job)
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro + Edit Upgrade | A | A | A | — |
| EmEditor | S | B | C | — |
| 010 Editor | B | C | F | — |
※ The 250 GB column is “—” for the same reason as in the viewing table. There is no 250 GB file on the Windows machine.
※ 010 Editor’s 50 GB is an F because the replace never finished (東京 → Tokyo was still at 20% after 10 minutes). Save itself did complete, in 589.1 s (11.81×). The same 50 GB replace finishes in 12 min 45 s on the Mac, so the reading is that rewriting 50 GB is simply too much for a 16 GB laptop.
Windows in short — 3 GB belongs to EmEditor. Editing is S (0.39×). Search 0.45×, replace 0.14× — both more than twice as fast as UwView Pro + Edit, and the gap widens the more you repeat the work. The crossover starts at 10 GB, where save balloons to 18.36× and editing drops to B, then C at 50 GB. Viewing is A at both 3 GB and 10 GB (at 10 GB EmEditor opens faster, 0.48×). PilotEdit has been removed for now — there is an open enquiry with its developer.73×, beating UwView Pro. But its 50 GB replace stalls at 20%, so editing is an F. klogg takes an A at 10 GB — open at 0.53×, half of UwView Pro, with search at 3.98×. For viewing alone it is a perfectly good choice on Windows (though the grade becomes B under a different denominator; see the note above). UltraEdit has been removed from the Windows table (measured without adjusting the large-file settings). Nothing at 250 GB was measured at all, because the file will not fit on the Windows machine.**
The 3 GB breakdown
| 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 time has more than doubled. If you routinely edit files of around 3 GB on Windows, EmEditor is the better choice. I would rather say so plainly.
ripgrep and amber also run on Windows, but they were measured on macOS, so they are not in this table (see the macOS one). If you have Windows numbers, I would be glad to hear them. 010 Editor and klogg were measured on both, so they appear in both tables — with separate values. UltraEdit was measured on both too, but the Windows side has been removed.
macOS
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro (viewing) | A | A | A | A |
| klogg (viewer only) | B | B | B | B |
| 010 Editor | B | B | B | B |
| UltraEdit | B | C | B | C※cfg |
| Log Viewer 1.3.0 (viewer only) | B | B | D | × |
| UwView (free, viewer only) | A | C | B | C |
| UwView Wasm build (Web, viewer only) | C | C | C | × |
| ripgrep (CLI) ※ | A | B | A | B |
| GNU grep (CLI) ※ | A | B | A | B |
| amber (CLI) ※ | A | A | B | B |
| BSD grep (CLI) ※ | B | B | B | B |
※ At 250 GB the combinations that produced a measurement were klogg, 010 Editor, UltraEdit, UwView (free), UwView Pro and the CLI tools.
※ lnav has been removed from this table (12 September 2026). Its author does not claim large-file support, and a per-file limit of 134,217,728 lines is documented in the source as a deliberate design choice. Placing it in the same table as tools that do advertise large-file handling was my mistake. It works without trouble up to 10 GB and 100 million lines (follow-up article).
※ UltraEdit cannot open the 250 GB file with its default settings. It opened only after switching to the “no temporary file” mode and moving the temp-file location to the external drive (12 September 2026). Left at the defaults, it ends after about a minute with no message at all. See the UltraEdit entry below “7. What ‘could not measure’ actually means”.
Log Viewer caused the Mac itself to reboot, so it is “×” (see “7. What ‘could not measure’ actually means”). The Log Viewer case has been reported to its developer, and a fix is on its way to the App Store (11 September 2026).
※ CLI tools have no “open” step. For those alone the grade is CLI search time ÷ UwView Pro’s (open + search). The GUI builds an index before it answers, so lining both up on “total time until the answer appears” is the fairer comparison.
※ On that basis the CLI tools land at A–B. The table in “2. Search” makes them look 4–9× slower, but that compares only the search that happens after the index exists. Include the time to build the index and the gap shrinks to 1.28–3.73×. If one or two questions are all you need, a CLI tool is enough — that is the honest summary.
※ In the macOS 3 GB column, 010 Editor and Log Viewer are upper bounds. Their 3 GB searches came in under one second and could not be timed, so they are counted as one second. The real grades may be better than shown.
※ The free UwView is in this table too. It opens and searches files up to 250 GB (measured 11 September 2026). The saved index and the compressed cache are Pro features, so the free build re-reads the file on every search.
| Size | Open | Search (2 words) | Geo. mean | Grade |
|---|---|---|---|---|
| 3 GB | 6.18 s (1.82) | 0.485 s (0.31) | 0.75 | A |
| 10 GB | 21.7 s (1.85) | 35.57 s (14.40) | 5.16 | C |
| 50 GB | 1 min 46.8 s (1.82) | 2 min 56.4 s (7.84) | 3.77 | B |
| 250 GB | 8 min 52.6 s (1.68) | 7 min 29.9 s (13.89) | 4.83 | C |
※ 3 GB is an A because the free build searched it faster than Pro (0.485 s against 1.555 s — 0.31×). That works out to 12.5 GB/s, which means it is reading from the OS page cache, not from disk. A 3 GB file fits inside 32 GB of RAM, so the whole thing is cached the moment it opens, and running a plain SIMD byte scan over it beats reading and decompressing the cache. This is my paid product losing to my free one, and I am leaving the number in.
※ That A does come with a caveat: the two figures are not from the same run. Pro’s 0.926 s / 0.629 s were measured on a different day, with no guarantee the cache state matched. Measuring both in one sitting is on the list (see “6. Combinations not yet measured”).
※ The free build’s speed barely changes with size. Open runs at 473–491 MB/s and search at 575–581 MB/s (leaving aside the cached 3 GB case). With no index, it simply reads. The ratio moves from 0.31 to 14.40 to 7.84 to 13.89 not because the free build changed, but because Pro did.
※ The UwView Wasm build runs in a browser, but it opened the same files from the same Mac, so it shares the table. For viewing alone, the Wasm build is in the same league as 010 Editor and UltraEdit (C at 3 GB, 10 GB and 50 GB).
※ Log Voyager has been removed from this table (12 September 2026). It is not a viewer you address by line: it is built as a seek bar that jumps by byte offset, as its author explains on Show HN. Measuring it against line-based metrics is not a comparison of quality. It is designed for peeking into a huge file in a browser — a different purpose.
Editing (the whole job)
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro + Edit Upgrade | A | A | A | A |
| 010 Editor | B | C | F | × |
| UltraEdit | C | C | C | × |
| CLI (ripgrep + sed) | C | C | B | C |
| CLI (BSD grep + sed) | C | C | B | C |
※ Measured as repeated work, the other tools generally drop one grade, because replace and save are paid five times. UltraEdit at 3 GB goes B → C, and the CLI pair goes B → C. For a single pass, UltraEdit at 3 GB is 3.64× and CLI (ripgrep + sed) is 2.32× at 3 GB, 1.55× at 10 GB and 1.68× at 50 GB (see “5. Whole-job totals”).
※ UltraEdit’s 10 GB and 50 GB replace and save were measured on 14 September 2026, and both came out C (10 GB: replace 12.53×, save 1.91×, repeated 9.00× / 50 GB: replace 4.30×, save 1.08×, repeated 4.29×). The ratio is smaller at 50 GB — because UwView Pro also needs real time at that size. The × at 250 GB is because the file never opened.
※ (This table is the Mac. The Windows results for 010 Editor are in the Windows table above.) 010 Editor can edit up to 10 GB. 3 GB was measured through replace and save on 14 September 2026 and came out B (replace 2.55×; save is a theoretical lower bound of 1.00×). 50 GB is an F because replace was measurable (16.28×) but save never finished — which does not mean slow; it means the job never ran to the end, so no total exists. The × at 250 GB is the replace that reached 99% after 1 h 47 min and then stopped responding. Viewing still reaches 250 GB (see the table above).
※ The CLI whole-job figure is search plus “replace and save” combined. With a CLI tool, replace and save are the same single pass (the output of sed). 22.68 s at 3 GB, 46.79 s at 10 GB, 298.70 s at 50 GB (ripgrep line).
macOS in short — EmEditor does not exist here, so at 3 GB there is no direct rival. UltraEdit opens files up to 50 GB (re-measured 14 September 2026). klogg and 010 Editor both reached 250 GB. UltraEdit cannot open it at its default settings; changing the temp-file settings opened it in 10 min 10 s (viewing C). Log Viewer made the Mac reboot and was abandoned. The two that got there both open faster than UwView Pro (0.81× and 0.90×) while search costs 8.15× and 8.82×. What decides it is not whether the file opens but how many questions you ask afterwards. For 010 Editor, only the 250 GB replace failed to finish (viewing reaches 250 GB).
At 3 GB nothing gives you trouble (measured side by side, 14 September 2026). Opening costs about 2×, and all three tools search in about a second. At 10 GB only search pulls apart — opening is 1.05× for 010 Editor and 1.32× for Log Viewer, almost level, yet search is 9.29× and 6.64×. At 50 GB the best of the others is 010 Editor (open 0.82×, search 5.02×, grade B).
The CLI tools are A–B at every size. Counting the time to build the index, the gap to UwView Pro is only 1.28–3.73×. If one or two questions are enough, a CLI tool will do.
The browser build (UwView Wasm) also matches 010 Editor and UltraEdit for viewing. No installation, and it opens and searches 3 GB to 50 GB.
Web (browser)
These are listed in the macOS table above, because they opened the same files from the same Mac.
The web in short — there is effectively one option that works entirely in a browser. The UwView Wasm build is a steady C at 3 GB, 10 GB and 50 GB, and for viewing alone it sits in the same league as 010 Editor and UltraEdit (3 GB: index 10.4 s, 東京 5.8 s). No install, no sign-up. At 3 GB and 100 million lines it is genuinely usable. 250 GB, however, stalled at 51% while loading — running in a browser has limits, and that territory belongs to the native build. The web version has no editing features.
Linux
Not a single measurement. The tools that support it are the UwView family, klogg, 010 Editor, UltraEdit, ripgrep, amber, GNU grep and sed (EmEditor is Windows-only). If you have real Linux numbers, please send them.
How to read the detailed tables
Everything below is the raw material behind the grades above.
- “Open” means the index is complete (the whole file is usable). Time to first screen is listed separately
- Save is measured as a
.uwvzwrite. Plain-text writes are noted separately - Replace and Save apply to editors only. Viewer-only tools have no such column
- Symbols in the tables
- a number … the ratio (UwView Pro = 1.00)
- OK … not measured at that size, but confirmed working at a larger size, so judged usable (downward inference)
- could not measure … did not finish, or the conditions could not be met. This may be a problem with my environment or settings. If a smaller size could not be measured, every larger size is treated the same way (upward inference). If the file would not open, search, replace and save are also unmeasurable, since they are never reached
- — … not applicable, or nothing to judge on
- The letters after a tool name are the operating systems it supports (which OS I measured on is in the table further down)
- W … Windows / M … macOS / L … Linux / Web … browser (no install)
- e.g. EmEditor (W) is Windows-only; UwView Pro (W/M/L) supports all three; the UwView Wasm build (Web) runs in a browser
- 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
- I am the developer of one side of this comparison (the UwView family). Please discount accordingly
Which OS each tool was measured on
| Measured on Windows | Measured on Mac | Measured on both |
|---|---|---|
| EmEditor | Log Viewer / grep / ripgrep / sed / amber | UwView family / 010 Editor / UltraEdit / klogg |
EmEditor is Windows-only and is not an option on a Mac. Log Viewer, conversely, was measured on the Mac.
ripgrep and amber run on Windows too, but I measured them only on the Mac. Please read every ratio below with that in mind.
010 Editor and klogg were measured on both Windows and Mac (14 September 2026). Below they appear as ⟨Mac⟩ and ⟨Win⟩. Only UltraEdit ⟨Mac⟩ remains in the tables. The UwView Pro figure they are compared against is from the same machine in each case. Do not compare a ⟨Mac⟩ ratio directly with a ⟨Win⟩ one — the denominators are different.
File sizes are rounded. “50 GB” is 51,254,526,392 bytes and 892,239,125 lines (some articles call it 48 GB or 51.25 GB — ÷1024³ versus ÷1000³; the same file). “250 GB” is 258,679,440,228 bytes and 4,509,830,821 lines.
Conclusions — what to use at each size
You do not need to read every table. This is the summary.
| Size | The realistic choice |
|---|---|
| up to 3 GB | On Windows, EmEditor wins outright. Replace is 7× faster than UwView Pro + Edit (0.14×) and search is more than twice as fast (0.45×). Opening is a draw (1.09×). Repeat the work and it stretches to 0.39× (editing grade S). There is no reason to switch in this range. EmEditor is Windows-only, though, and does not exist on the Mac (on a Mac at 3 GB, UltraEdit is the nearest thing, but replace is 10.76×). UltraEdit has been removed from the Windows table (settings were not adjusted) |
| 10 GB | This is where it turns over. EmEditor still opens fast (0.48×) and holds search to 1.92×, but save is 18.36×, and repeated editing comes to 3.07×. 010 Editor’s save is 27.84× (Mac). 010 Editor does open 10 GB quickly, though — 1.05× on the Mac and 0.73× on Windows, beating UwView Pro |
| 50 GB | For viewing, the other GUIs are still in the fight. Opening is roughly level (010 Editor 0.82×, UltraEdit 1.21×, klogg 1.59×); search is where they separate (010 Editor 5.02×, UltraEdit 7.33×, klogg 8.95×, Log Viewer 39.64×). For viewing alone, 010 Editor is the best of the others (B). What becomes decisive is editing and saving — EmEditor takes 47 min 13 s for the whole job, UltraEdit 11 min 33 s (3.08× of 2 min 53 s; 4.29× when repeated), 010 Editor never completes the save (Mac) and stalls at 20% on the replace on Windows |
| 250 GB | Four GUIs opened and searched it: klogg, 010 Editor, UltraEdit (settings changed) and the UwView family. (UltraEdit needs its temp-file setting changed and takes 10 min 10 s to open.) The three that open without any change are 4–5 minutes, essentially level (klogg 0.81×, 010 Editor 0.90× — both faster than UwView Pro). But one search is enough to reverse it (klogg 8.15×, 010 Editor 8.82×, because both re-read all 258 GB for every search). The only GUI that got as far as editing and saving was UwView Pro + Edit — 010 Editor’s replace reached 99% after 1 h 47 min and then stopped responding, so completion was never confirmed |
In other words, the options thin out as the file grows. At 3 GB everyone competes; at 50 GB most drop out; by 250 GB the tools that can still view are klogg, 010 Editor and the UwView family. UwView Pro exists because of those last two columns.
But “opens” and “usable” turned out to be different things. Opening 250 GB takes 4–5 minutes in all three of those. The difference shows up from the second search onwards, and at the point where you edit and save. See “250 GB — four GUIs opened it, one got as far as editing” below.
If you work with files around 3 GB on Windows, EmEditor is the better choice. I would rather write that plainly.
1. Open — until the index is complete (the whole file usable)
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro (W/M/L) | 1.00 | 1.00 | 1.00 | 1.00 |
| UwView (free) (W/M/L) | 1.82 | 1.85 | 1.82 | 1.68 |
| EmEditor (W) | 1.09 | 0.48 | 3.96 | — |
| klogg ⟨Mac⟩ (W/M/L) | 1.93 | 1.73 | 1.59 | 0.81 |
| klogg ⟨Win⟩ (W/M/L) | 1.56 | 0.53 ※ | 1.25 | — |
| 010 Editor ⟨Mac⟩ (W/M/L) | 2.00 | 1.05 | 0.82 | 0.90 |
| 010 Editor ⟨Win⟩ (W/M/L) | 1.85 | 0.73 | 1.75 | — |
| UltraEdit ⟨Mac⟩ (W/M/L) | 1.24 | 1.12 | 1.21 | 1.92※cfg |
| Log Viewer 1.3.0 (M) | 1.92 | 1.32 | 5.95 | could not measure |
| UwView Wasm build (Web) | 3.07 | 4.88 | 5.22 | could not measure |
On the first open, UwView Pro sometimes loses. klogg at 250 GB is 0.81×; 010 Editor at 50 GB is 0.82×. Building an index puts it at a disadvantage on the very first pass.
※ On klogg ⟨Win⟩ at 10 GB (0.53×) — the denominator is a UwView Pro open of 29.3 s (an earlier measurement). On 14 September 2026 a value of 8.11 s also appeared, which would make this 1.91×. That run was discarded as a pair because EmEditor’s open was inexplicably slow in it (14.0 s → 31.1 s). The upshot is that the number I am using favours klogg. I will update this row once UwView Pro is re-measured on the Windows machine.
About EmEditor at 3 GB / 10 GB — re-measured on 14 September 2026, EmEditor came out at 9.7 s / 31.1 s against UwView Pro’s 3.71 s / 8.11 s: EmEditor alone was more than twice as slow. There is no explanation for one side alone slowing down under identical conditions, so that run’s “open” is not used. The 1.09× and 0.48× in the table are EmEditor 5.0 s / 14.0 s against UwView Pro 4.6 s / 29.3 s.
The same thing happens at 250 GB. klogg opens the 258 GB file in 4 min 18 s (258.3 s) and 010 Editor in 4 min 44.9 s (284.9 s), both faster than UwView Pro’s 317.8 s (0.81× and 0.90×). Building the index costs UwView Pro the first pass.
The difference appears from the second time on. At 50 GB UwView Pro reopens in 0.02–0.07 s (restored from a compressed cache); klogg pays 110 s every time (re-indexing); EmEditor needs about 4 minutes to reopen. At 250 GB klogg pays its 258.3 s again on every reopen.
Time to first screen / time to reach the end (reference)
| Tool | First screen (10 GB / 50 GB) | Reaching the end |
|---|---|---|
| UwView family (native) (W/M/L) | under 1 s / under 1 s | instantly on open |
| UwView Wasm build (Web) | under 1 s / under 1 s | after the index completes |
| Log Viewer 1.3.0 (M) | 10 s / 50 s | after the index completes |
| EmEditor (W) | first screen only | 4 min 06 s (50 GB) |
The first thing you do in an incident is look at the newest log lines — that is, the end of the file. The native UwView jumps to the end the moment it opens; Log Viewer and the Wasm build have to wait for the index (350 s and 307 s at 50 GB).
2. Search
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro (W/M/L) | 1.00 | 1.00 | 1.00 | 1.00 |
| UwView (free) (W/M/L) | 0.31 | 14.40 | 7.84 | 13.89 |
| klogg ⟨Mac⟩ (W/M/L) | 4.65 | 2.63 | 8.95 | 8.15 |
| klogg ⟨Win⟩ (W/M/L) | 3.81 | 3.98 | 3.14 | — |
| EmEditor (W) | 0.45 | 1.92 | 8.15 | — |
| 010 Editor ⟨Mac⟩ (W/M/L) | 1.29 ※ | 9.29 | 5.02 | 8.82 |
| 010 Editor ⟨Win⟩ (W/M/L) | 2.00 | 4.78 | 3.45 | — |
| UltraEdit ⟨Mac⟩ (W/M/L) | 5.64 | 15.38 | 7.33 | 15.36※cfg |
| Log Viewer 1.3.0 (M) | 1.29 ※ | 6.64 | 39.64 | could not measure |
| UwView Wasm build (Web) | 7.14 | 9.65 | 13.51 | could not measure |
| BSD grep (M) | 5.94 | 8.98 | 5.84 | 11.05 |
| GNU grep (ggrep) (M/L) | 4.07 | 8.79 | 5.30 | 8.45 |
| ripgrep 15.2.0 (W/M/L) | 4.10 | 8.80 | 5.36 | 8.58 |
| amber 0.6.1 (W/M/L) | 4.09 | 8.52 | 6.28 | 11.05 |
The search terms are 東京 (“Tokyo”) and 大阪 (“Osaka”) for the Japanese files, and “New York” and others for the 250 GB file. The ratios widen as the file grows. Log Viewer is 6.64× at 10 GB and 39.64× at 50 GB.
The four CLI tools (GNU grep / ripgrep / amber / BSD grep) at 3 GB, 10 GB and 50 GB were measured on 14 September 2026. Details in the next section. Only the 250 GB column is a five-question workload, and there GNU grep and amber are one measured question multiplied by five.
EmEditor at 3 GB / 10 GB was re-measured on 14 September 2026 (see the section below). At 3 GB EmEditor searches more than twice as fast (0.45×). At 10 GB it is still ahead at 1.92×.
※ The 3 GB figures for 010 Editor and Log Viewer are upper bounds. Both came in under one second, which a stopwatch cannot resolve, so they are counted as one second; the real values are smaller.
CLI numbers are per question. If you only have one question, ripgrep is faster (there is no point building an index); from the second question onwards it reverses. At 250 GB the crossover was at question 1.29.
Four CLI tools on Japanese data: almost identical (14 September 2026)
The 3 GB and 10 GB CLI rows had been “OK” placeholders; these are now measured. The search terms are the same 東京 and 大阪 used on the GUI side, and the figures are the two combined. All five tools agreed exactly on hit counts (3 GB 11,274 / 5,560; 10 GB 11,393 / 6,268; 50 GB 94,979 / 53,210).
| 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 (ambs) |
6.37 s | 21.06 s | 141.50 s |
BSD grep (LC_ALL=C) |
9.25 s | 22.20 s | 131.48 s |
| BSD grep (UTF-8) | 8.48 s | 22.14 s | 126.68 s |
| UwView Pro + Edit | 1.555 s | 2.47 s | 22.5 s |
At 10 GB and above, it hardly matters which CLI tool you use. Fastest to slowest differ by 1.05× at 10 GB and 1.19× at 50 GB. Effective throughput per pass explains why.
| Tool | 3 GB | 10 GB | 50 GB |
|---|---|---|---|
| GNU grep | 958 MB/s | 944 MB/s | 859 MB/s |
| ripgrep | 949 MB/s | 943 MB/s | 849 MB/s |
| amber | 952 MB/s | 974 MB/s | 724 MB/s |
BSD grep (LC_ALL=C) |
656 MB/s | 924 MB/s | 780 MB/s |
They all flatten 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.
There are two exceptions. BSD grep at 3 GB manages 656 MB/s — two-thirds of the ceiling, and is 1.46× slower than GNU grep. If macOS’s stock grep feels slow, installing GNU grep through Homebrew (it appears as ggrep) is worth it. The other is amber at 50 GB, 724 MB/s, 1.19× slower than GNU grep. The 258 GB run showed the same pattern (details).
The gap to UwView Pro + Edit is widest at 10 GB.
| Size | ripgrep | Why the gap widens or narrows |
|---|---|---|
| 3 GB | 4.10× | UwView Pro takes 1.555 s. At this size the index does not buy much |
| 10 GB | 8.80× | UwView Pro is still at 2.47 s. This is the widest point |
| 50 GB | 5.36× | UwView Pro stretches to 22.5 s, so the gap closes |
| 250 GB | 8.58× | Five questions. The more you ask, the wider it gets |
The ratio falls at 50 GB not because the CLI got faster. UwView Pro went from 2.47 s to 22.5 s. The CLI scaled straightforwardly, 21.75 s to 120.70 s.
But that 4–9× is “after the index exists”
The ratios above compare search alone. The GUI built an index first. The CLI has no such step. Line both up on total time until the answer appears and it looks like this.
| 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× |
※ The 250 GB column alone is a five-question comparison (the others are the two words 東京 and 大阪).
4–9× shrinks to 1.28–3.73×. The part that had been ignored — the time to build the index — was the gap.
And I think this is the most honest table on the page. If one or two questions are enough, a CLI tool will do. At 3 GB, ripgrep takes 6.39 s against UwView Pro’s 4.945 s — only 1.29×. The index pays for itself when you ask the same file many questions. At 250 GB it is 2.90× over five questions and 5.76× over twenty (the crossover maths).
That total is why the CLI tools sit at A–B in the overview table.
250 GB — four GUIs opened it, one got as far as editing (re-measured 14 September 2026)
klogg, 010 Editor and UwView Pro can all open and search the 258 GB file. But only UwView Pro + Edit got as far as editing and saving.
Open (until the index is complete)
| Tool | Measured | vs UwView Pro | vs physical floor |
|---|---|---|---|
| klogg (viewer only) | 4 min 18.3 s (258.3 s) | 0.81 | 0.96 |
| 010 Editor | 4 min 44.9 s (284.9 s) | 0.90 | 1.06 |
| UwView Pro | 5 min 17.8 s (317.8 s) | 1.00 | 1.18 |
All three are 4–5 minutes, essentially level — and the order is klogg, then 010 Editor, with UwView Pro last. Building an index and a compressed cache costs it the first pass. The “physical floor” is the time for wc -l to read 258 GB once (268.49 s); all three are pinned to a single read-through.
Search
| Tool | New York | Statue of Liberty | Avg of 2 | vs UwView Pro |
|---|---|---|---|---|
| klogg | 4 min 18.9 s (258.9 s) | 4 min 28.9 s (268.9 s) | 263.9 s | 8.15 |
| 010 Editor | 4 min 47.8 s (287.8 s) | 4 min 43.1 s (283.1 s) | 285.5 s | 8.82 |
| UwView Pro | — | — | 32.38 s | 1.00 |
For klogg and 010 Editor, a search costs about as much as opening the file. Both are pinned to the physical floor (0.98× and 1.06×). In other words, every search reads all 258 GB again. UwView Pro answers in 32.38 s because it is consulting an index.
Total after opening and asking N questions
| Tool | Open only | 1 question | 5 questions |
|---|---|---|---|
| UwView Pro | 5 min 18 s | 5 min 50 s | 8 min 00 s |
| klogg | 4 min 18 s | 8 min 42 s | 26 min 18 s (3.29×) |
| 010 Editor | 4 min 45 s | 9 min 30 s | 28 min 32 s (3.57×) |
| ripgrep (CLI, reference) | — | 4 min 38 s | 23 min 10 s |
The lead lasts only until the file is open. By the end of the first search it has already reversed (UwView Pro 5 min 50 s against klogg’s 8 min 42 s and 010 Editor’s 9 min 30 s). The 317.8 s spent on the 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. If one question is all you need, ripgrep (4 min 38 s) remains the fastest.
Replace — 010 Editor never finished
I ran a replace-all of “New York” → “NYC” in 010 Editor. It was about a third done at 19 min 00 s, kept going, and reached 99% at 1 h 47 min — at which point it stopped responding and completion could not be confirmed.
Getting to 99% and not finishing is, I think, the heaviest result in this whole exercise. One hour and 47 minutes of waiting, and nothing to show for it.
| Method | Time for the same replace |
|---|---|
| UwView Pro + Edit Upgrade | 62.0 s |
sed (transform only) |
741.48 s (12 min 21 s) |
sed (including writing the real file) |
999.38 s (16 min 39 s) |
| 010 Editor | 99% at 1 h 47 min, never completed |
Because of this, 010 Editor sits in the “viewing” bracket in the overview. It was practical for opening and searching 250 GB, but it never reached editing and saving. This may be a problem with settings or environment.
The ones that did not get there
| Tool | What was observed |
|---|---|
| UltraEdit | ~~Cannot open it with the default settings~~ → it opened in 10 min 10 s once the settings were changed (12 September 2026). The cause was the temp-file location: it defaults to the boot disk, could not reserve 258 GB there, and gave up after about a minute without showing anything. See the UltraEdit section above |
| Log Viewer 1.3.0 | Trying to open it repeatedly caused the Mac itself to reboot. Abandoned as unsafe |
| UwView Wasm build (my own) | Loading stopped at 51% and went no further. It works up to 50 GB |
My own Wasm build does not get there either. Running in a browser has limits; 250 GB is native territory.
Log Viewer at 250 GB is a different kind of “could not measure.” It is not slow, and it does not fail to finish — it takes the OS down with it. I would not recommend trying it on a 250 GB file. Something about its memory use looks wrong, but I cannot say what. It may well be specific to my environment, so I would like the developer to check. Up to 50 GB it works (though search costs 39.64×).
klogg is viewer-only, so it has no replace or save column.
UltraEdit — opens up to 50 GB, does not open 250 GB (14 September 2026)
It warns about degraded performance above 5 GB, so I had been avoiding large tests. Measured, it opens files up to 50 GB without trouble.
| Size | Open | 東京 | 大阪 | UwView Pro + Edit (open / 東京 / 大阪) |
|---|---|---|---|---|
| 10 GB | 13.15 s | 20.1 s | 17.9 s | 11.75 s / 1.24 s / 1.23 s |
| 50 GB | 1 min 11 s (71 s) | 1 min 23 s (83 s) | 1 min 22 s (82 s) | 58.8 s / 11.1 s / 11.4 s |
| 250 GB | gives up silently after ~1 min; never opens | — | — | 5 min 17.8 s (317.8 s) |
As ratios, opening is level at every size.
| Size | Open | Search (2 words) | Viewing grade |
|---|---|---|---|
| 10 GB | 1.12 | 15.38 | C (geometric mean 4.15) |
| 50 GB | 1.21 | 7.33 | B (geometric mean 2.98) |
| 250 GB | could not measure | — | × |
The 10 GB search at 15.38× is the widest value among the tools measured this time. It narrows to 7.33× at 50 GB, but that is because UwView Pro also needs eleven-odd seconds at 50 GB — UltraEdit did not get faster (20.1 s → 83 s).
250 GB never opened in ten minutes. klogg opens the same file in 4 min 18 s and 010 Editor in 4 min 44.9 s. This may be a problem with settings or environment.
※ The UwView Pro figures at 50 GB are from the previous day (index 58.8 s, 東京 11.1 s, 大阪 11.4 s). The 10 GB pair was measured side by side on the same day.
Replace and save at 10 GB and 50 GB were also measured (14 September 2026)
| Size | Operation | UltraEdit | UwView Pro + Edit | Ratio |
|---|---|---|---|---|
| 10 GB | 東京 → Tokyo | 45.1 s | 3.6 s | 12.53 |
| 大阪 → Osaka | 43.5 s | 3.6 s | 12.08 | |
Save (.uwvz basis) |
11.1 s | 5.8 s | 1.91 | |
| Save (plain-text basis) | 11.1 s | 12.3 s | 0.90 | |
| 50 GB | 東京 → Tokyo | 3 min 22 s (202 s) | 47.0 s | 4.30 |
| 大阪 → Osaka | 3 min 21 s (201 s) | 47.0 s | 4.28 | |
Save (.uwvz basis) |
54.1 s | 49.9 s | 1.08 |
Saving is close to a draw. Writing 10 GB as plain text, UltraEdit is actually faster (0.90×), and 50 GB is 1.08×. The gap is in replace — 45.1 s per word at 10 GB, 3 min 22 s per word at 50 GB. Pay that five times and replace alone costs 33 minutes at 50 GB.
Measured as repeated work (open → (search + replace) × 5 → save), it is 9.00× at 10 GB (651.75 s against 72.4 s) and 4.29× at 50 GB (2965.1 s against 691.2 s) — a C in both cases.
The ratio falls as the file grows — 9.00× at 10 GB down to 4.29× at 50 GB. UltraEdit did not get faster; UwView Pro also needs 47 s for a replace at 50 GB. UltraEdit is fast enough to open and read up to 50 GB; it gets heavy once you rewrite repeatedly.
※ The 10 GB search was run twice that day (東京 20.1 / 大阪 17.9, and 東京 18.5 / 大阪 18.4). The two differ by less than 3%, so the table keeps the first run. Replace and save come from the same run as the second.
※ The 50 GB save of 54.1 s sits right on the disk’s write ceiling (51,254,526,392 bytes ÷ 54.1 s = 947 MB/s, against an effective ~0.9 GB/s). I treat that as stopwatch error and keep it.
010 Editor / Log Viewer vs UwView Pro + Edit — measured side by side on the Mac (14 September 2026)
Same Mac, same external USB SSD, same files, three tools, one day.
| Size | Operation | 010 Editor | Log Viewer 1.3.0 | UwView Pro + Edit |
|---|---|---|---|---|
| 3 GB, 100 M lines | Open | 6.78 s | 6.5 s | 3.39 s |
| 東京 | under 1 s | under 1 s | 0.926 s | |
| 大阪 | under 1 s | under 1 s | 0.629 s | |
| 東京 → Tokyo (replace) | 3.34 s | — (viewer only) | 1.31 s | |
| 大阪 → Osaka (replace) | 2.03 s | — (viewer only) | 1.31 s ※ | |
| Save | 3.5 s ※T | — (viewer only) | 3.5 s | |
| 10 GB, 100 M lines | Open | 12.3 s | 15.5 s | 11.75 s |
| 東京 | 11.46 s | 9.5 s | 1.24 s | |
| 大阪 | 11.48 s | 6.9 s | 1.23 s |
As ratios:
| Size | Item | 010 Editor | Log Viewer |
|---|---|---|---|
| 3 GB | Open | 2.00 | 1.92 |
| Search (2 words) | 1.29 ※ | 1.29 ※ | |
| Viewing grade | B (geo. mean 1.61 ※) | B (geo. mean 1.57 ※) | |
| Replace (1 word) | 2.55 | — (viewer only) | |
| Save | 1.00 ※T | — (viewer only) | |
| Editing grade | B (repeated 1.70) | — (viewer only) | |
| 10 GB | Open | 1.05 | 1.32 |
| Search (2 words) | 9.29 | 6.64 | |
| Viewing grade | B (geo. mean 3.12) | B (geo. mean 2.96) | |
| 50 GB | Open | 0.82 | 5.95 |
| Search (2 words) | 5.02 | 39.64 | |
| Viewing grade | B (geo. mean 2.03) | D (geo. mean 15.36) |
※ All three searched 3 GB in about a second, and the two others could not be timed with a stopwatch. They are counted as one second, an upper bound, so the real ratios are smaller.
※ The 1.31 s replace for UwView Pro + Edit at 3 GB is an earlier measurement (per word); two words are calculated as 2.62 s.
※T — 010 Editor’s save is a theoretical value. The stopwatch said 1.0 s, but writing 3.03 GB in one second means 3 GB/s, which this disk cannot do (i.e. it was never actually measured). Using the fastest write observed on the same machine and disk, 877 MB/s, writing 3,032,812,644 bytes takes 3.5 s, and that is the lower bound I use. Nothing can write faster than that, so it is the most generous value available to 010 Editor.
At 3 GB there is barely any difference. Opening costs about 2×, and search is too fast to time. Nothing gives you trouble in this range. Even including editing, repeated work is 1.70× (open → (search + replace) × 5 → save: 47.13 s against 27.77 s). At 3 GB, editing in 010 Editor is still practical. It pulls apart at 10 GB and 50 GB.
At 10 GB only search separates. Opening is 1.05× for 010 Editor and 1.32× for Log Viewer, almost level, yet search is 9.29× and 6.64×. Whether a tool has an index starts to matter here.
At 50 GB the two diverge. 010 Editor is 0.82× to open (faster than UwView Pro) and 5.02× to search, a B; Log Viewer is 5.95× and 39.64×, a D. For viewing alone, the best of the others at 50 GB is 010 Editor (東京 56 s, 大阪 57 s).
How this differs from earlier figures — I used to give 5.23× for 010 Editor’s 10 GB search. 010 Editor barely moved: 11.5 s → 11.46 s. What changed is UwView Pro + Edit, 2.2 s → 1.24 s. The same applies to Log Viewer: the move from 5.00× to 6.64× is mostly UwView Pro + Edit getting faster. The newer figures were all taken on the same day on the same machine, so those are the ones I use.
010 Editor measured on Windows too — the same tool on two machines (14 September 2026)
010 Editor was the first tool on this page measured on both Windows and Mac. It shows how much the machine matters for one and the same application.
Measured on Windows (16 GB laptop)
| Size | Operation | 010 Editor | UwView Pro + Edit | Ratio |
|---|---|---|---|---|
| 3 GB | Open | 8.5 s | 4.6 s | 1.85 |
| 東京 | 2.5 s | 1.49 s | — | |
| 大阪 | 2.2 s | 0.86 s | — | |
| Search (2 words) | 4.7 s | 2.35 s | 2.00 | |
| Replace (2×) | 28.5 s | 6.3 s | 4.52 | |
| Save | 4.9 s | 3.2 s | 1.53 | |
| 10 GB | Open | 21.5 s | 29.3 s | 0.73 |
| Search (2 words) | 27.05 s | 5.66 s | 4.78 | |
| Replace (2×) | 67.6 s | 12.41 s | 5.45 | |
| Save | 76.8 s | 10.2 s | 7.53 | |
| 50 GB | Open | 2 min 13 s (133.2 s) | 76.1 s | 1.75 |
| Search (2 words) | 2 min 45 s (165.1 s) | 47.8 s | 3.45 | |
| Replace | still 20% after 10 min; abandoned | 47.0 s | could not measure | |
| Save | 9 min 49 s (589.1 s) | 49.9 s | 11.81 |
Viewing is a B at all three sizes (geometric means 1.92, 1.87, 2.46). At 10 GB it opens at 0.73× — against the 29.3 s UwView Pro spends building an index, 010 Editor is up in 21.5 s. The Mac shows the same pattern (1.05× at 10 GB, 0.82× at 50 GB), so being quick to open survives a change of machine.
What separates them is, again, the second search onwards. 010 Editor re-reads the file for every search, so the time stacks up with the number of questions.
Editing is B at 3 GB, C at 10 GB, F at 50 GB. The 50 GB replace of 東京 → Tokyo was still at 20% after ten minutes and was abandoned. Save itself completes, in 589.1 s, so what jammed was the replace.
The same 010 Editor on Windows and on 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 |
| 10 GB | Search (2 words) | 27.05 s | 22.94 s |
| 50 GB | Open | 133.2 s | 56.7 s |
| 50 GB | Search (2 words) | 165.1 s | 113 s |
| 48–50 GB | Replace (1×) | abandoned at 20% | 12 min 45 s (765.3 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 stalling at 20% on Windows.
I read this as a problem with rewriting 50 GB on 16 GB of RAM rather than a problem with 010 Editor. As stated at the top, the numbers on this page assume “a modest laptop handling a gigantic file.” On a machine with plenty of RAM, a 50 GB replace may well go through on Windows too.
※ The Windows UwView Pro + Edit figures at 3 GB, 10 GB and 50 GB are earlier measurements (open 4.6 / 29.3 / 76.1 s). The only thing re-measured on the same day as 010 Editor was EmEditor’s search, which is in the section after next.
klogg measured on Windows too — an A at 10 GB (14 September 2026)
klogg is viewer-only, so there is only open and search.
| Size | Operation | klogg ⟨Win⟩ | UwView Pro ⟨Win⟩ | Ratio |
|---|---|---|---|---|
| 3 GB | Open | 7.18 s | 4.6 s | 1.56 |
| 東京 | 4.58 s | 1.49 s | — | |
| 大阪 | 4.38 s | 0.86 s | — | |
| Search (2 words) | 8.96 s | 2.35 s | 3.81 | |
| Viewing grade | B (geo. mean 2.44) | |||
| 10 GB | Open | 15.5 s | 29.3 s | 0.53 ※ |
| Search (2 words) | 22.5 s | 5.66 s | 3.98 | |
| Viewing grade | A (geo. mean 1.45) | |||
| 50 GB | Open | 1 min 35 s (95.2 s) | 76.1 s | 1.25 |
| Search (2 words) | 2 min 30 s (150.1 s) | 47.8 s | 3.14 | |
| Viewing grade | B (geo. mean 1.98) |
klogg is steady on Windows as well. Search stays within 3.1–4.0× across all three sizes, and the ratio barely grows with file size. Given that on the Mac it stretched to 8.95× at 50 GB and 8.15× at 250 GB, klogg is doing relatively better on this Windows machine — which really means UwView Pro is the slower one there.
The A at 10 GB is the highest grade any third-party tool takes on this page. Open is 0.53× — klogg builds no index, so the first pass is cheap.
※ That 0.53× depends on the denominator, though. I am using a UwView Pro 10 GB open of 29.3 s (an earlier measurement), but 8.11 s also appeared on 14 September 2026. With that, it becomes 1.91×, a B. That run was discarded as a pair because EmEditor’s open in it was inexplicably slow, so the number in use happens to favour klogg. I will update this once UwView Pro is re-measured on the Windows machine.
I am not comparing these with the Mac figures. The Mac klogg numbers are reference values measured as “two runs combined”, while the Windows ones are a single run. The bases differ, and putting them side by side would mislead.
About the UltraEdit Windows measurements
They have been removed. They were taken without adjusting the large-file settings (Large Files, and how temporary files are handled). The Mac measurements stand.
EmEditor vs UwView Pro + Edit — measured side by side on Windows (14 September 2026)
Same day, same machine, same files, both tools. This is the cleanest comparison, with no environmental difference in it.
| Size | Operation | EmEditor | UwView Pro + Edit | Ratio |
|---|---|---|---|---|
| 3 GB, 100 M lines | Open ※ not used | 9.7 s | 3.71 s | (2.61) |
| 東京 | 0.51 s | 1.49 s | 0.34 | |
| 大阪 | 0.55 s | 0.86 s | 0.64 | |
| Search, 2 words total | 1.06 s | 2.35 s | 0.45 | |
| 10 GB, 100 M lines | Open ※ not used | 31.1 s | 8.11 s | (3.83) |
| 東京 | 7.03 s | 2.87 s | 2.45 | |
| 大阪 | 3.82 s | 2.79 s | 1.37 | |
| Search, 2 words total | 10.85 s | 5.66 s | 1.92 |
At 3 GB EmEditor searches more than twice as fast (0.45×). At 10 GB that narrows to 1.92×. The picture of an index paying off as the file grows appears cleanly across these two rows.
Only “open” is not used (see below). The open ratios in the tables, 1.09× and 0.48×, come from earlier measurements.
Why “open” from that run is not used
In that session, EmEditor’s open went from 5.0 s to 9.7 s (3 GB) and 14.0 s to 31.1 s (10 GB) — more than twice as slow. UwView Pro went the other way on the same day, 29.3 s → 8.11 s (10 GB). If the storage were responsible, both should have moved in the same direction; one side alone slowing down has no explanation. Since I could not identify the cause, the “open” figures come from the earlier measurements. Search moved consistently for both, so those figures are used.
3. Replace (editors only)
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro + Edit Upgrade (W/M/L) | 1.00 | 1.00 | 1.00 | 1.00 |
| EmEditor (W) | 0.14 | 2.30 | 14.30 | — |
| 010 Editor ⟨Mac⟩ (W/M/L) | 2.55 | 5.14 | 16.28 | could not measure |
| 010 Editor ⟨Win⟩ (W/M/L) | 4.52 | 5.45 | could not measure | — |
| UltraEdit ⟨Mac⟩ (W/M/L) | 10.76 | 12.53 | 4.30 | could not measure |
| BSD sed (M) | OK | OK | OK | 11.96 |
On a 3 GB replace I lose outright to EmEditor (0.14× — seven times faster). I am not going to hide that. For a small file, loading it into memory and rewriting it is simply quicker. The differential approach starts to pay from 10 GB.
※ 010 Editor ⟨Mac⟩ at 3 GB (2.55×) was measured on 14 September 2026. 東京 → Tokyo 3.34 s, 大阪 → Osaka 2.03 s. Against 5.14× at 10 GB, you can see the gap widening with size.
※ 010 Editor ⟨Win⟩ is compared on two replacements combined (3 GB 28.5 s against 6.3 s; 10 GB 67.6 s against 12.41 s), because on Windows the UwView Pro figure also exists only as a two-replacement measurement. At 50 GB, 東京 → Tokyo was still at 20% after ten minutes and was abandoned.
※ UltraEdit ⟨Mac⟩ at 10 GB (12.53×) and 50 GB (4.30×) were also measured on 14 September 2026. 10 GB: 45.1 s and 43.5 s; 50 GB: 3 min 22 s (202 s) and 3 min 21 s (201 s). It is the only tool in this table whose ratio falls as the file grows — not because UltraEdit got faster, but because UwView Pro also needs 47 s at 50 GB.
4. Save (editors only, measured as a .uwvz write)
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro + Edit Upgrade (W/M/L) | 1.00 | 1.00 | 1.00 | 1.00 |
| EmEditor (W) | 1.59 | 18.36 | 37.27 | — |
| 010 Editor ⟨Mac⟩ (W/M/L) | 1.00 ※T | 27.84 | could not measure | — |
| 010 Editor ⟨Win⟩ (W/M/L) | 1.53 | 7.53 | 11.81 | — |
| UltraEdit ⟨Mac⟩ (W/M/L) | 1.14 | 1.91 | 1.08 | could not measure |
| sed (writing a real file) (M) | OK | OK | OK | 7.24 |
This is where the spread is widest. UwView Pro + Edit Upgrade never rewrites the original; it accumulates changes as a differential, so saving mid-session costs zero seconds (the differential already exists). EmEditor needs 31 minutes every time at 50 GB.
※T — 010 Editor’s 3 GB save is a theoretical value. The stopwatch said 1.0 s, but writing 3.03 GB in 1.0 s means 3 GB per second, which this disk cannot produce (i.e. it was never actually measured). Using the fastest write observed on the same Mac and the same external USB SSD (877 MB/s), 3,032,812,644 bytes ÷ 877 MB/s = 3.5 s, and that is the lower bound I used. No tool can write faster than that, so it is the most generous value available to 010 Editor. It is not a measurement.
※ UltraEdit ⟨Mac⟩ at 10 GB (1.91×) and 50 GB (1.08×) were measured on 14 September 2026. 11.1 s and 54.1 s, against UwView Pro + Edit’s .uwvz writes (5.8 s and 49.9 s). Compared with the 12.3 s plain-text write at 10 GB it is 0.90× — essentially level. The difference appears when you save repeatedly during a session.
※ UltraEdit ⟨Mac⟩’s 50 GB save of 54.1 s sits on the disk’s write ceiling. Writing 51,254,526,392 bytes in 54.1 s is 947 MB/s, slightly above this external USB SSD’s effective ~0.9 GB/s. I treat that as stopwatch error and keep it, but the possibility that the operation returned before the write flushed remains.
Writing 250 GB out as plain text took 323.9 s. That output is byte-for-byte identical to the sed output (258,678,935,268 bytes, exact match).
5. Whole-job totals — “open it, find it, fix it, save it”
Not individual operations, but the entire job measured end to end.
This table is a single pass. The editing grades in the overview are five repetitions, so the numbers differ. For a single pass the CLI is ahead (2.32× at 3 GB); repeated, it falls behind (5.35× on the same file). The difference is whether you re-read and re-write everything each time, or carry only a differential.
| Tool | 3 GB | 10 GB | 50 GB | 250 GB |
|---|---|---|---|---|
| UwView Pro + Edit Upgrade (W/M/L) | 1.00 | 1.00 | 1.00 | 1.00 |
| EmEditor (W) | 0.78 | 4.43 | 16.38 | — |
| 010 Editor ⟨Mac⟩ (W/M/L) | 1.60 | 7.98 | could not measure | could not measure |
| 010 Editor ⟨Win⟩ (W/M/L) | 2.83 | 3.35 | could not measure | — |
| UltraEdit ⟨Mac⟩ (W/M/L) | 3.64 | 4.44 | 3.08 | could not measure |
| CLI (ripgrep + sed) (M/L) | 2.32 | 1.55 | 1.68 | 4.11 |
| CLI (BSD grep + sed) (M) | 2.62 | 1.57 | 1.74 | 4.64 |
At 3 GB I lose to EmEditor (0.78×). And at 50 GB it opens to 16.38×. Same opponent, same operations — only the size changes.
※ The Windows figures for EmEditor and UwView Pro + Edit are the whole job measured end to end. 010 Editor and UltraEdit are the sum of individually measured steps (open + search of 2 words + 2 replacements + save); they were not timed end to end. 010 Editor ⟨Mac⟩ at 3 GB is 17.65 s against 11.07 s; 010 Editor ⟨Win⟩ is 46.6 s against 16.45 s at 3 GB and 192.95 s against 57.57 s at 10 GB; UltraEdit ⟨Mac⟩ is 149.75 s against 33.72 s at 10 GB and 11 min 33 s (693.1 s) against 3 min 45 s (225.2 s) at 50 GB.
The underlying measurements:
| 3 GB | 10 GB | 50 GB | |
|---|---|---|---|
| EmEditor (W) | 11.0 s | 229.9 s | 47 min 13 s |
| UwView Pro + Edit (W/M/L) | 14.1 s | 51.91 s | 2 min 53 s |
The CLI breakdown (Mac, 14 September 2026)
| 3 GB | 10 GB | 50 GB | |
|---|---|---|---|
| Search, 2 words (ripgrep) | 6.39 s | 21.75 s | 120.70 s |
| Search, 2 words (BSD grep) | 9.25 s | 22.20 s | 131.48 s |
Replace and save (sed) |
16.29 s | 25.04 s | 178.00 s |
| Total (ripgrep + sed) | 22.68 s | 46.79 s | 298.70 s |
| Total (BSD grep + sed) | 25.54 s | 47.24 s | 309.48 s |
| UwView Pro + Edit (open + search + replace + save) | 9.76 s | 30.12 s | 2 min 58 s |
With a CLI tool, replace and save are one and the same step — a single sed substitution pass whose output goes to a new file. It reads, rewrites and writes out in one go. The ratios are 1.55–2.62×, much smaller than the 4.11× at 250 GB. At 50 GB and below, doing the work with CLI tools is entirely realistic.
※ The UwView Pro + Edit figure it is compared against is an estimate: open + search + replace + save. 3 GB = 3.39 + 1.555 + 1.31 + 3.5 = 9.76 s; 10 GB = 11.75 + 2.47 + 3.6 + 12.3 = 30.12 s; 50 GB = 58.8 + 22.5 + 47.0 + 49.9 = 178.2 s. Open and search are measurements from 14 September 2026; replace and save come from a different day.
Note — the Windows figures in this table are earlier measurements. In the side-by-side run of 14 September 2026, UwView Pro + Edit’s open came out at 3.71 s / 8.11 s (down from the 4.6 s / 29.3 s used here). Replace and save have not been re-measured, so the totals are unchanged. I will swap them in once they are.
The 250 GB figure covers five searches, four drill-down stages, an aggregation, a replace-all and a save. CLI 51 min 17 s against 12 min 29 s (finishing with a .uwvz write). Writing plain text instead took 15 min 35 s, a ratio of 3.29×.
6. Combinations not yet measured
Among the blank cells, these are the ones that could be measured and have not been. They will be filled in.
| Tool | Not measured | Notes |
|---|---|---|
| UwView Pro + Edit (W/M/L) | Replace and save at 3 GB / 10 GB / 50 GB on the Mac | The CLI side was measured on 14 September 2026. Only the GUI replace and save are carried over from another day, so re-measuring them together would settle the totals |
| UwView Pro + Edit (W/M/L) | Replace and save at 3 GB / 10 GB on the Windows machine | Open and search have been re-measured |
| ~~UwView (free) (W/M/L)~~ | ~~Measured open and search at every size~~ | Filled in on 11 September 2026 (viewing A / C / B / C). What remains is measuring 3 GB in one sitting — the free build’s 0.485 s and Pro’s 1.555 s come from different days, so the cache state may not match |
| GNU grep (ggrep) (M/L) | The five-question workload at 250 GB | The 8.45× in the table is one measured question (273.66 s) multiplied by five |
| EmEditor / 010 Editor ⟨Win⟩ / klogg ⟨Win⟩ (W) | 250 GB | I have not been able to put a 250 GB file on the Windows machine. With one, the Windows ceiling would become clear |
| UwView Pro + Edit (W/M/L) | Re-measuring “open” on the Windows machine | 3 GB 4.6 s / 10 GB 29.3 s / 50 GB 76.1 s are earlier measurements. 3.71 s / 8.11 s also appeared on 14 September 2026, and which one is used as the denominator decides whether klogg ⟨Win⟩ at 10 GB is an A or a B |
| ~~UltraEdit (W/M/L)~~ | ~~Replace and save at 10 GB / 50 GB~~ | Filled in on 14 September 2026 (10 GB editing C, 50 GB editing C). 250 GB is out of scope because the file never opens |
klogg and 010 Editor both reach 258 GB (re-measured 14 September 2026; see “2. Search” above).
The 3 GB figures for the UwView Wasm build were measured on 14 September 2026 (index 10.4 s, 東京 5.8 s, 大阪 5.3 s). That leaves almost no “OK” placeholders in the tables.
010 Editor’s 3 GB replace and save were also measured on 14 September 2026 (東京 → Tokyo 3.34 s, 大阪 → Osaka 2.03 s). Only the save is a theoretical value — the stopwatch said 1.0 s, but writing 3.03 GB in one second means 3 GB per second, which this disk cannot do. Since it was never really measured, I use the 3.5 s derived from the fastest write observed on the same disk (877 MB/s) as a lower bound. Measuring it properly would mean checking the file size and modification time after the write completes.
7. What “could not measure” actually means
These are the combinations that produced no value. Because a problem with my environment or settings is always possible, I do not describe them as defects in the tools. I record only what was observed.
| Tool | Size | What was observed |
|---|---|---|
| 010 Editor ⟨Mac⟩ (W/M/L) | 50 GB | A text save did not complete after more than 15 minutes; no final file was produced |
| 010 Editor ⟨Win⟩ (W/M/L) | 50 GB | A replace-all of 東京 → Tokyo was still at 20% after 10 minutes and was abandoned (14 September 2026). Save itself completes, in 589.1 s. The same 50 GB replace finishes in 12 min 45 s on the Mac |
| 010 Editor ⟨Mac⟩ (W/M/L) | 250 GB | A replace-all reached 99% at 1 h 47 min, then stopped responding; completion could not be confirmed |
| Log Viewer 1.3.0 (M) | 250 GB | Trying to open it repeatedly caused the Mac itself to reboot. Measurement abandoned as unsafe. → Reported to the developer, who replied the same day saying he had found and fixed two causes (11 September 2026): (1) a path that could still load the whole file into memory rather than memory-mapping it, now memory-map only, failing safely otherwise; (2) line-index construction queueing too many memory-heavy updates, now sharing its data and capping the queue. The fix is going to the App Store. This “×” belongs to 1.3.0 |
| UwView Wasm build (Web) | 250 GB | Loading stopped at 51% and went no further (14 September 2026). Apparently a browser-side limit |
| ~~UltraEdit ⟨Mac⟩ (W/M/L)~~ | ~~250 GB~~ | Resolved (12 September 2026). Moving the temp-file location to the external drive and switching to the “no temporary file” mode opens it in 10 min 10 s. Left at the defaults it still ends after about a minute with nothing on screen — that part remains, and we are asking the developer about it |
amber (ambr) |
250 GB | In-place replacement needs the original plus a temporary file, 516 GB in total. With 401 GB free it could not run |
These are results on my machines. Different settings or conditions may produce different results. If you know better, please tell me. I will verify and correct.
Any “×” not listed above comes from upward inference.
The GUIs that opened 250 GB were four: klogg, 010 Editor, the native UwView, and UltraEdit once its temp-file setting was changed. My own UwView Wasm build stops at 51%.
Log Viewer at 250 GB is a different kind of “could not measure.” Trying to open it repeatedly made the Mac itself reboot. This is not about being slow or not finishing, so I would not recommend handing a 250 GB file to 1.3.0.
I reported this to the developer directly (11 September 2026). He replied the same day, saying he had found and fixed two causes — (1) a path that could still load the whole file into memory instead of memory-mapping it (it now uses memory mapping only, and fails safely when that is not possible), and (2) line-index construction queueing too many memory-heavy updates (the index now shares its data and caps the queue). He also confirmed that 4.5 billion lines is not itself a problem. The fix is going to the App Store.
He does not, however, have the free disk space to build a real 258 GB file, so the fix is verified against a sparse file of the same size rather than the real thing. I will run the real file myself once the update ships, and update this entry.
Related articles — the exact conditions behind every cell
Head-to-head with other tools
- I compared it with klogg, and the design turned out to be a generation behind
- The full benchmark — klogg vs UwView Pro across 3 GB/10 GB/48 GB × HDD/SSD/internal SSD
- An honest comparison with klogg — everything I win and everything I lose, in one table
- A 48 GB file you can “open” still cannot be investigated — compared with EmEditor
- Editing a 48 GB file and saving partway through — compared with EmEditor
- Editing huge files is not about “can it open” but “how often can you stop” — 010 Editor and UltraEdit on a Mac ARM
- Losing at 3 GB, a cliff at 50 GB — measured against EmEditor on a 16 GB laptop
- Just search and replace — EmEditor, klogg, grep, 010 Editor and UltraEdit at three sizes
- Is ripgrep really fastest on a single gigantic file? Measured on 51 GB and 890 million lines
- Is “open a 100 GB log in your browser” true? Log Voyager and the UwView Wasm build on 47 GB
- Follow-up Tests — What I Learned by Re-testing the “Handles Huge Files” Claim
- Five questions against 258 GB and 4.5 billion lines — where grep loses to a GUI
Quick reference and practical guides
- I fed ten comparison articles to an AI, and got a size-by-size cheat sheet back
- How to open and search a 50 GB log file on a 16 GB laptop
- Before you give up and load that 100-million-line text file into a database
- CLI commands → UwView Pro equivalents
My own measurements
- Opening 258.68 GB and 4.5 billion lines — the whole of the United States from OpenStreetMap, expanded to XML
- How much slower is the same UwView in a browser? Native vs WASM on identical files
- 21,994 replacements across 100 million lines and 10 GB in 16.8 seconds. The file grew by 3.7 MB
- How many search threads is right? Measured on 890 million lines from 1 to 16 threads
- Benchmarks on a fanless Mac varied by 54% — thermal throttling and round-robin measurement
Try it — start in the browser
If the tables above made you wonder how your own files would behave, this is the order I would suggest.
1. The Wasm build first — no install, free
Up to about 3 GB and 100 million lines, the web version is genuinely usable.
On 3.03 GB and 100 million lines the measurements were 10.4 s to finish the index, 5.8 s for a full-text search of 東京 and 5.3 s for 大阪 (14 September 2026). Context display and jumping are instant. You just open it in a browser — no installation, no sign-up.
To be straight about it, the Wasm build has a high up-front cost. On the same 3 GB file, the desktop build (UwView Pro + Edit) opens in 3.39 s and searches in about a second — a difference of three to seven times. On the other hand it scales gracefully, holding a C at 10 GB and 50 GB alike; at 50 GB its 307 s index beat Log Viewer’s 350 s. Even so, if you work with large files every day, the native build is far more comfortable. 250 GB stalled at 51% while loading.
2. UwView, free — enough if you only need to read
The free desktop application. Tail (following appended lines) is a feature of the free version, not of Pro.
It opens and searches files up to 250 GB (measured 11 September 2026: 8 min 52.6 s to open, about 7 min 30 s per search). At 3 GB its viewing grade is A, and its search beats Pro (0.485 s against 1.555 s) — at that size the file sits in RAM, so scanning it plainly is faster than consulting an index. The saved index and the compressed cache are Pro features, so the gap opens past 10 GB (10 GB C, 50 GB B, 250 GB C). Around 3 GB, and if you are not going to search the same file many times, the free build is enough.
→ Download
3. UwView Pro / + Edit Upgrade — once you pass 10 GB
Runs on Windows, macOS and Linux, and one licence covers all three. One-time purchase or monthly, with a 14-day free trial — the editing features are included.
On Windows, at around 3 GB, EmEditor is faster in places. The gap opens once you go past 10 GB. Start with the free Wasm build and see how many seconds your own file takes to open, then decide.
Please note
The information on this page is provided for reference and carries no guarantee of accuracy or completeness. The ratios shown are approximations that place measurements from different dates, operating systems and storage devices in a single table. Tool versions are those current at the time of measurement. If you spot an error, please let me know — I will verify and correct it.