DEV Community: y4u

How to Open a 50GB Log File — and Reopen It in 0.05 Seconds. A klogg Alternative, Benchmarked

y4u — Sat, 29 Aug 2026 03:10:12 +0000

If you searched for a klogg alternative, you probably already know klogg is good. It is fast, it is free, it is open source, and it runs on Windows, macOS and Linux. Most people who go looking for something else are not unhappy with klogg as a viewer. They are unhappy with one specific moment in their day:

Opening the file again.

You investigated a 48GB log yesterday. You closed it. This morning your colleague asks about a different error, and you have to wait through the whole index build a second time. On a USB HDD that is nine minutes of staring at a progress bar — and while it builds, klogg only shows you the beginning of the file.

That is the problem this article is about. Below is a measured comparison on a real 47.73GB file, including the rows where klogg wins.

The test


File	OpenStreetMap Japan `japan-latest.osm` — 47.73 GB, 892,239,125 lines
Machine	MacBook Air / Apple M4 (10 cores) / 32GB RAM
Storage (measured with `dd`)	USB HDD 0.10 GB/s ／ USB SSD 0.41 GB/s ／ Internal SSD 3.29 GB/s
Versions	klogg 24.11.0 ／ UwView Pro

Search hit counts were verified to match exactly across klogg, UwView Pro, and a direct search of the raw file — so we know both tools are answering the same question.

The numbers

	klogg 24.11.0	UwView Pro	Ratio
First open	HDD ~9 min ／ USB SSD ~110 s ／ Internal SSD ~15 s — every time	HDD 10.6 min ／ USB SSD 138.5 s ／ Internal SSD 23.3 s — first time only	klogg wins
Reopening	Same as the first open (re-indexes every time)	0.01–0.07 s	~1,250–50,000x
Search, literal `"Tokyo"`	~585 s ／ 120–135 s ／ 15–20 s	74.8 s ／ 14.3 s ／ 5.1 s	~7.8x ／ ~9x ／ 3–4x
Search, regex `"Tok[yi]o"`	≈ literal (I/O bound, pattern-independent)	29.8 s (USB SSD) ／ 11.0 s (Internal SSD)	~4.4x ／ ~1.5x
Disk used to keep the file	48 GB (original required)	5.3 GB (original can be deleted)	1/9

Two things are worth saying plainly.

klogg opens the file faster the first time. UwView Pro is slower on the first open because it is building a compressed cache while it reads. That is a real cost and we are not going to hide it.

You pay klogg's cost every single time. UwView Pro pays it once.

Why the difference exists

klogg builds its line index in memory. Close the window and the index is gone. This is a perfectly reasonable design — it keeps the tool simple and leaves nothing behind on your disk.

UwView Pro writes a compressed sidecar cache next to your file: a single .uwvz file with the line index built in and a checksum to detect corruption. The next time you open the file, there is nothing to rebuild. The index is already there.

The cache is also why the search is faster. Searching the .uwvz means reading roughly one ninth as many bytes off the disk. The slower your storage, the bigger the gap — on a USB HDD, a literal search drops from about ten minutes to 75 seconds.

There is a second consequence that surprised us more than the speed did. Because the .uwvz contains everything needed to read the file, you can delete the original 48GB and still browse and search the log at 5.3GB. For teams that keep finished incident logs "just in case," that changes the storage math.

One more thing: you can move around while it indexes

klogg shows you the head of the file until indexing finishes. You cannot jump to the middle or the end.

UwView displays by byte position, so the whole file is navigable the moment you open it. Jump to the end of a 258GB file at 10% indexed and it will show you the end. We have done exactly that on a 4.5-billion-line file — the entire United States OpenStreetMap extract expanded to XML, 258.68 GB.

If your workflow is "open it, immediately jump to the timestamp where things broke," this matters more than raw index speed.

When you should stay with klogg

This is the section most comparison articles leave out.

Your files are under a few gigabytes. At 3GB and 100 million lines the two tools are within seconds of each other on search. klogg's re-index at that size is 47 s / 8 s / 2 s depending on storage — annoying, not painful. The case for switching is weak.

You open each file exactly once. All of UwView Pro's advantage is amortised across reopens. If you genuinely never come back to a file, you are paying the slower first open for nothing.

You want open source. klogg is open source. UwView is not.

You need to edit. UwView is a viewer, not an editor. If you need to change the file, neither klogg nor UwView will help you.

You are on Windows and cannot accept an unsigned binary. The Windows build of UwView Pro is currently unsigned, which means SmartScreen will warn you (More info → Run anyway). If your organisation blocks that, this is a hard stop for now.

When UwView Pro makes sense

You reopen the same large files. This is the whole argument. If a 20GB log gets opened three times over a week, klogg costs you three full index builds and UwView Pro costs you one.

Your storage is slow. Network shares, external drives, spinning disks. The gap widens as bandwidth drops, because the compressed cache reads a ninth of the bytes.

You are archiving. Keeping investigated logs at 1/9 the size, still directly openable, with checksum protection. We wrote about that workflow separately.

Your files are genuinely enormous. We have measured 4.5 billion lines. We do not know where the ceiling is.

What about the other klogg alternatives?

If you browse the alternatives listed for klogg, you will find a long tail of log viewers — GamutLogViewer, LogExpert, Chainsaw, Logbert, WinTail and others. Many of them are good at things klogg is not: structured log parsing, live tailing, colour rules per log format, database-backed search.

Most of them are also Windows-only, and — more to the point — most were not designed with a 48GB single file in mind. "Log viewer" covers two quite different problems: understanding structured logs and surviving enormous files. If your problem is the first one, a purpose-built log analyser will serve you better than either klogg or UwView.

UwView is built for the second problem, and only for that.

Free version vs Pro

UwView (free) opens huge files with the same byte-position navigation. On first open it is comparable to klogg and other tools. No sidecar cache, so reopening re-reads.

UwView Pro adds the compressed .uwvz cache: instant reopen, faster search, 1/9 storage. one-time or monthly, and one licence covers Windows 10/11, macOS 11+ (Apple Silicon and Intel), and Linux x86_64.

There is also a browser build (WASM) if you want to try the interface without installing anything, though it is naturally slower than native.

Update (Aug 26, 2026): the search gap has since reversed

When this article was written, klogg's Boolean search was one of the rows where klogg won. UwView Pro v1.3.0+ changed that with two new modes: Drill-down search (refine results with the next term, up to 8 stages in tabs — narrowing co-occurrence across nearby lines, which single-line Boolean can't do) and Sequence search (only the flows where w1 → w2 → w3 appear in that order — the local-file equivalent of EQL's sequence, with no klogg counterpart). Details: Drill-down / Sequence. Everything else in this article, including the rows klogg wins, is unchanged.

[In Development] Editing a 48GB File and Saving Mid-Way: EmEditor vs UwEditor Pro

y4u — Sat, 29 Aug 2026 03:09:09 +0000

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

Last time we compared "opening a 48GB file and searching it." This time we go one step further — editing it, and saving part-way through.

Same PC, same 48GB file, same search term. The conditions are held constant.

The comparison is again against EmEditor Professional. On Windows it is the practical benchmark for large-file work. And as we wrote last time, EmEditor is far ahead on editing features. That has not changed.

What changed is that the UwView side now has editing.

Results first

Operation	EmEditor (mean of 2 runs)	UwEditor Pro	Ratio
Open the file	103.6 s (116.8 / 90.4)	107.1 s	Tie — EmEditor is marginally faster
Search for `東京` (94,979 matching lines)	194.7 s (245.3 / 144)	23.9 s	~8x
Replace all `東京` → `Tokyo`	210.5 s (257 / 164)	35.9 s	~6x
Mid-work save (to stop and come back)	31 min (1,860 s)	0 s (instant)	—
Final write-out (produce one file)	the same operation again — 31 min	1 min 33 s	~20x

The EmEditor figures are the mean of two runs; both individual values are in brackets, because the spread is not small.

Opening is a tie — if anything EmEditor is slightly ahead. Everything after that is where the gap opens.

Where this comparison applies — below ~10GB, EmEditor is faster

Let me draw the boundary before anything else.

The test machine has 16GB of RAM. A 48GB file does not fit in it. Every number above comes from that condition.

At around 10GB — a file that fits in RAM — EmEditor is markedly faster at both search and replace. On a machine with plenty of RAM, EmEditor stays fast on genuinely large files too.

EmEditor is a capable, feature-rich editor, and more than sufficient for ordinary "large" files. Macros, CSV editing, fine-grained regex control, plugins — on editing features there is no contest.

UwEditor Pro only pulls ahead once the file exceeds available memory — that region and nothing else. It was built for that one case; this is not a claim about which is the better editor.

If you open 10GB logs every day, use EmEditor. This article only starts to matter when your files outgrow your RAM.

Test environment

Item	Value
PC	HP Spectre x360 (same machine as last time)
OS	Windows 11 Home (x64)
CPU	Intel Core i7-1165G7 2.80GHz (4 cores / 8 threads)
RAM	16GB
Storage	Internal SSD
Test data	OpenStreetMap Japan
File size	~48 GB (the same file as last time)
Lines	~892 million
Encoding	UTF-8
Search term	`東京` (Tokyo, in Japanese)
EmEditor	Professional 64-bit v26.2.5 (same as last time)
UwEditor Pro	v1.3.3 (development build)

Both products, same PC, same SSD, same file.

1. Opening — a tie

EmEditor 103.6 s (mean of 116.8 s and 90.4 s) / UwEditor Pro 107.1 s.

On this one item, EmEditor came out slightly ahead.

As we wrote last time, the first open produces no dramatic gap — both have to physically read 48GB. We are not going to claim a win here.

The difference appears from the second open onward, because UwEditor Pro stores a compressed index (.uwvz). But that is not the subject of this article.

2. Search — 245.3 s becomes 23.9 s

Searching for 東京 matches 94,979 lines. Both products returned the same count — which is to say, they are answering the same question.

	Time
EmEditor (run 1 / run 2)	245.3 s / 144 s → mean 194.7 s
UwEditor Pro	23.9 s

About 8x. Three minutes, or twenty-four seconds. Once is noise; investigation means running dozens of searches.

Part of this gap is thread count

To be precise about what the number means: this 8x is not algorithm alone.

EmEditor was configured to use 8 threads. In practice it appeared to run on a single thread — presumably an automatic decision based on available memory and file size. UwEditor Pro ran on 8 threads.

So the gap includes a difference in the parallelism actually used under these conditions. On a machine with memory to spare, EmEditor would run in parallel and the gap would narrow.

This is not a defect in EmEditor. It is the constraint imposed by handling 48 GB with 16 GB of RAM — which is precisely what this article is about.

EmEditor's second run dropped sharply, 245.3 s → 144 s (the OS file cache, presumably). Even against the faster 144 s, UwEditor Pro is 6x.

The reason is the same as last time: UwEditor Pro is reading a compressed index, not the raw 48GB. Fewer bytes off the disk, less time.

3. Replace — 257 s becomes 35.9 s

Replacing every 東京 with Tokyo.

	Time
EmEditor (run 1 / run 2)	257 s / 164 s → mean 210.5 s
UwEditor Pro	35.9 s

About 6x. Against the faster 164 s it is still 4.6x.

4. Mid-work saving — the question of whether you can stop

This is the difference that matters most in practice.

Editing a huge file is not a single pass. You replace, you check, you fix something else — and you want to save along the way. Before lunch. Before switching tasks. And simply because you do not want to lose what you have done.

A normal editor rewrites the whole file on every one of those saves. Change one spot in 48GB and you write 48GB back out. In this test, EmEditor's save took 31 minutes (started 0:17, finished 0:48).

This is not a story about saving being slow. It means you cannot save part-way — you cannot stop. A 31-minute save cannot be inserted at every natural break in the work. Three saves and an hour and a half has gone to saving. You either finish the 48GB edit in one unbroken run, or you lose it.

UwEditor Pro's mid-work save measured 0 seconds — done the instant you press it.

The reason is non-destructive overlay editing. The .uwvz (compressed index) stays immutable; only the edit diff accumulates in .ewvz. Only the diff is written, so it finishes instantly regardless of how large the original is. In a separate test, 21,994 changes to a 10.09GB file produced a diff of 3.7MB — 0.037% of the original.

And the .ewvz is on disk throughout the edit. If it crashes before you save, your edits are still there.

"0 seconds" here means the mid-work save

Producing one final file — reconstructing a new .uwvz from the .uwvz + .ewvz — is a separate operation, and that one does take time proportional to size. That is the next section.

5. Final write-out — 31 minutes becomes 1 min 33 s

When the work is done, you write the result out as a single file. UwEditor Pro reconstructs a new .uwvz from the immutable index plus the edit diff, in a single pass.

	Time
EmEditor (rewrites the whole file)	1,860 s (31 min)
UwEditor Pro (`.uwvz` reconstruction)	93 s (1 min 33 s)

About 20x.

For EmEditor this is the same operation as the mid-work save. Every save, mid-work or final, rewrites 48GB. UwEditor Pro spends 0 seconds on the mid-work ones and pays 1 min 33 s once, at the end.

The reason is simple: what it writes out is a compressed index, not a raw 48GB file.

In the two previous articles we said we would measure the final write-out separately. This is that number.

What happens when you come back the next day

Editing a huge file is rarely a one-day job. So let's include opening the same file again tomorrow.

Day 1 — open, search & replace, save

	EmEditor	UwEditor Pro
Open	103.6 s	107.1 s
Search & replace	405.2 s	59.8 s
Save (to stop and come back)	1,860 s (31 min)	0 s
Total	~39.5 min	~2.8 min

About 14x. There is no "save" time on the UwEditor Pro side, because only the diff is written.

Day 2 — reopen the same file, finish the edit, write it out

	EmEditor	UwEditor Pro
Reopen	103.6 s	too fast to time (milliseconds)
Search & replace	405.2 s	59.8 s
Write out as one file	1,860 s (31 min)	93 s (1 min 33 s)
Total	~39.5 min	~2.5 min

EmEditor pays exactly the same 39.5 minutes on day 2. It reads 48 GB again, and writes 48 GB again.

On the UwEditor Pro side, "open" disappears. The index (.uwvz) is already on disk, so reopening could not be timed with a stopwatch — it happens in milliseconds. In its place, the final write-out costs 1 min 33 s, once.

What these two tables show

On day 1 the saving design does the work — only the diff is written, so it costs 0 s.
On day 2 the index design does the work — nothing has to be read again.

They are two separate designs, and they pay off on different days. EmEditor spends the same 39.5 minutes on both. Day 3, day 4 — the gap keeps widening by that amount.

Again: these are the numbers for a 16 GB-RAM machine handling a 48 GB file. For a file that fits in RAM, EmEditor finishes first.

Being straight about the limits

UwEditor Pro is in development and not for sale. There is no release date.
EmEditor is ahead on editing features. Macros, CSV editing, fine-grained regex control, plugins — UwEditor Pro is a narrow tool for "changing a huge file without breaking it," not a replacement for EmEditor.
At around 10GB — a size that fits in RAM — EmEditor is markedly faster at both search and replace. These results are for a 16GB-RAM machine handling 48GB. Change that condition and the order changes.
The search gap includes a difference in thread count. EmEditor was set to 8 threads but appeared to run on one (presumably an automatic decision from memory and file size); UwEditor Pro ran on 8. With memory to spare, that gap should narrow.
EmEditor was measured twice; we published both the mean and the individual values. The two runs differ by up to 1.7x (the OS file cache, presumably). Even against the faster value, the gap holds.
UwEditor Pro was measured once per operation.
EmEditor's save time (31 min) is the difference between start and finish times.
In the day-2 table, every figure except "reopen" repeats the day-1 measurement (it is the same operation). UwEditor Pro's reopen was too fast to measure — milliseconds.
This comparison is about one thing: changing a huge file and saving it. It is not a statement about everyday editing.

How it relates to UwView Pro

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

[In Development] I Replaced 21,994 Occurrences in a 10GB, 100-Million-Line File in 16.8 Seconds

y4u — Sat, 29 Aug 2026 03:08:10 +0000

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

This is what happened when UwEditor Pro — Huge Files, No Rewriting was pointed at a 100-million-line file.

What I did was simple: open a 10.09GB XML file and replace every occurrence of 東京 (Tokyo, in Japanese) with Tokyo.

Here is the result first.

Operation	Measured
Search for `東京` (21,948 matching lines)	3.7 s
Replace all `東京` → `Tokyo` (21,994 occurrences)	16.8 s
Extra disk space the edit consumed	3.7 MB

And — the original 10.09GB file was not modified by a single byte.

The file


File	A split of the OpenStreetMap Japan extract, `japan-dv-aa` (XML)
Size	10.09 GB
Lines	100,000,000 (exactly 100 million)
Encoding	UTF-8 (auto-detected)
Machine	macOS / UwEditor Pro (development build)
Storage	External USB SSD (measured with `dd` at 0.41 GB/s), not the internal drive

1. Open it

The status bar reads Total 100,000,000 lines. This part is the same as UwView Pro: the whole file is readable, scrollable and searchable the moment it opens. The index already lives in the .uwvz compressed cache, so line numbers are there from the start.

2. Enter edit mode

Pressing Edit in the toolbar reveals a replace bar under the search bar. Alongside Replace next and Replace all there are Delete matching lines, Delete selection, Replace selection and Delete this line — the operations you actually reach for when cleaning up logs.

3. Count what you are about to change

Before replacing anything, I counted with drill-down search: 21,948 hits in 3.7 seconds. A hundred million lines in under four seconds is possible because the search reads the compressed index (.uwvz, 1.38GB) rather than the raw 10.09GB — and this is on an external USB SSD measured at 0.41 GB/s, not the internal drive (3.29 GB/s on the same machine).

The list shows 東京 scattered across operator names, place names and Wikipedia references — <tag k="operator" v="東京臨海高速鉄道"/>, <tag k="wikipedia" v="ja:大久保駅 (東京都)"/>, and so on.

4. Replace all

Type Tokyo into the replacement field, press Replace all, and a confirmation appears:

Replace 21,994 occurrences? (A single undo will revert this.)

Why 21,948 and 21,994 disagree

The search says 21,948, the replace says 21,994 — a gap of 46. That is not a bug. The two numbers count different things.

The search list counts lines that contain a match.
The replace counts occurrences that will actually be rewritten.

One line in the list above reads v="東京急行電鉄;東京地下鉄" — two occurrences on a single line. Forty-six lines were like that.

5. Run it

21,994 occurrences replaced. Press Undo (Cmd/Ctrl+Z) once to revert.

16.8 seconds, for 21,994 changes inside 100 million lines.

And the whole thing reverts with one undo. The replacements are not 21,994 separate history entries; they are one operation.

6. Verify

Searching again for Tokyo now returns 23,147 hits.

The file already contained Tokyo on 1,153 lines (in name:en tags, mostly), and the replacement stacked on top of that. Look closely and you can see entries like v="ja:大塚駅 (Tokyo都)" — nonsense as Japanese, but exactly what a correct replacement should produce.

Jumping from a result lands you on the line itself — here, around line 73,000. Viewing and searching stay fully alive while the file is being edited.

7. Now look at the file sizes

This is the actual point of the article.

File	Size	Modified	What it is
`japan-dv-aa`	10.09 GB	July 16, 2026	the original XML
`japan-dv-aa.uwvz`	1.38 GB	August 24, 2026	compressed cache + index (~1/7)
`japan-dv-aa.ewvz`	3.7 MB	today, 21:33	the edit

Look at the modification dates. Twenty-two thousand changes were made, and neither the original (July 16) nor the index (August 24) moved. They were never touched.

The only thing created today is a 3.7 MB .ewvz — 0.037% of the 10.09GB file.

Why it works this way

A normal text editor rewrites the entire file every time you save. Change one line in a 10GB file and you write 10GB back out. That is why editing huge files is slow, and why a failure halfway through can destroy the original.

UwEditor Pro uses non-destructive overlay editing.

The .uwvz (compressed cache + index) is immutable. It is only ever read.
Edits accumulate as a diff in .ewvz — a record of what was changed to what.
What you see on screen is the composite of the two.

So the cost of an edit does not depend on the size of the file. Whether it is 10GB or 100GB, changing one line costs the same.

There is a second, quieter property that matters in practice. In the screenshots above the app still reports "editing (unsaved)" — and the .ewvz is already on disk. If it crashes before you save, your edits are still there.

Being straight about the limits

UwEditor Pro is in development and not for sale. There is no release date.
These are single measurements on macOS, against a file on an external USB SSD — not the internal drive — that had already been converted to .uwvz. The internal SSD on the same machine runs at 3.29 GB/s, so these numbers should shrink there (same machine and same method as our 3-size, 3-storage benchmark). Slower storage will stretch them instead.
16.8 seconds is the cost of editing, not of writing out. Pressing Save reconstructs a new .uwvz from the .uwvz + .ewvz in a single pass, and that does take time proportional to size.
- [Update, Aug 29, 2026] We measured it. On Windows, with a 48 GB file, the write-out took 1 min 33 s. Saving the same file in EmEditor — which rewrites the whole file — took 31 minutes, about 20x longer. Details → Editing a 48 GB file, and saving mid-way
The edit target is a .uwvz file. UwEditor Pro standardises on .uwvz as the thing it edits.

How it relates to UwView Pro

UwEditor Pro is a superset of UwView Pro. The drill-down search used above, and the instant reopen, come along unchanged — editing is added on top.

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

If 10GB costs 0.037%, 100GB should cost about the same proportion. If you have a file that breaks it, we would like to hear about it — that is how we found out 890 million lines was not the limit.

Find Only Where 'New York Central Park coffee_shop' Appear in That Order — Sequence Search on a 258 GB Local File

y4u — Wed, 26 Aug 2026 12:45:55 +0000

A follow-up to Drill-down Search: the same tabbed UI now has a second mode, Sequence Search.

What does searching by "order" mean?

Drill-down finds words that occur near each other. Sequence Search finds order: only the places where w1 → w2 → w3 appear in that sequence.

In log terms: you want only the spots where "login → timeout → restart" happened in that order. An and/or search can only say "all three words are present" — but an incident is a story, and stories have order. A different order is a different incident.

In the security world this is exactly Elastic EQL's sequence and Splunk's transaction — but both require the data to be ingested into a server first. Almost nothing lets you do this against a multi-gigabyte file sitting on your own machine.

Real example: 1,246 "New York → Central Park → coffee_shop" flows in 4.5 billion lines

The cover image is the entire US OpenStreetMap extract — 258.68 GB, 4,509,830,821 lines, searched directly from its compressed .uwvz archive:

New York (100,492) → Central Park (2,798) → coffee_shop (1,246)

"New York" appears 100,492 times. 2,798 of those are later followed by "Central Park" — and 1,246 flows continue on to "coffee_shop". Note how different this is from Drill-down on the same three words (100,492 → 226 → 3): Drill-down finds the words near each other; Sequence links occurrences in order, however far apart — the flow in the screenshot chains hits tens of thousands of lines apart (line 151,568,463 → 151,599,349 → 151,616,193). Usage is identical to Drill-down: switch the refine bar's mode to "Sequence" and keep adding words.

If an earlier word reappears mid-match, the automaton restarts from it (New York → Central Park → another New York? Matching resumes from the new New York). What survives is only the clean, uninterrupted flow.

The path itself is visible — the History menu

My favorite part of this implementation is the right-click menu on any result.

Open History (drill-down path) and you see the position of every word that formed that sequence — e.g. "line 151,568,463: New York → line 151,599,349: Central Park → line 151,616,193: coffee_shop" — and you can jump to the file at any of those lines.

No reverse-engineering "why did this line match?" in your head. You see the actual path of the matched flow, and you can walk it. Even EQL and Splunk don't show it this directly.

Speed

Each stage of Sequence Search scans the file body starting from the previous stage's result positions. The starting points are narrowed, but the processing itself is equivalent to a full-text search — so each stage takes roughly as long as a full-text search. This is the one way it differs from Drill-down, where stages after the first are instant (Drill-down only re-searches inside the previous stage's ±N context blocks). As with Drill-down, the ±N context lines are set independently per stage.

Get it

Drill-down and Sequence Search ship in UwView Pro V1.3 — released and available now. The free edition keeps the classic single-stage search with ±1 context and result export.

UwView Pro V1.3 is available on Polar. The monthly subscription comes with the first month free (the one-time purchase has no free trial).

Buy UwView Pro (Polar — one-time $129 / $9 per month, first month free): https://buy.polar.sh/polar_cl_37MuoKb8WjSfLZ7hhjaTTzwAVBxu2XyqbnuWe3aGzbj
UwView Pro product page: https://uvp.y42u.net/en/pro-en/
Free UwView: https://github.com/amru195704/UwView

One more thing: **UwEditor Pro, an editing-capable superset of UwView Pro built on the same huge-file engine, is currently in development. More on that soon.

From 100,492 Hits to 3 in Two Clicks — Drill-down Search for Huge Local Files

y4u — Wed, 26 Aug 2026 12:38:41 +0000

UwView Pro just gained Drill-down Search: refine your search results with another term, then another — up to 8 stages, each in its own tab.

It's the grep pipeline you already type every day

When you dig through a big log on the command line, you write something like:

grep -C 5 "ERROR" huge.log | grep "timeout" | grep "db-server3"

"Find ERROR, keep 5 lines of context, then keep only the chunks that also mention timeout, then db-server3." Drill-down Search is exactly that pipeline — as GUI tabs.

Run a normal search and the results pop up as usual (same as the free edition). In Pro, the popup has a refine bar: type the next term, hit Refine, and a new tab appears containing only the matches found within the ±N context of the previous stage. Each tab shows term (count), so you can watch the numbers collapse.

Real example: finding one coffee shop in 258 GB / 4.5 billion lines

The cover image is the entire US OpenStreetMap extract — one XML file of 258.68 GB and 4,509,830,821 lines, opened directly from its compressed .uwvz archive without unpacking:

New York (100,492) → Central Park (226) → coffee_shop (3)

"New York" alone: 100,492 hits in 30.28 s. Refine with "Central Park": 226. Refine with "coffee_shop": 3. Two refinements took 100k hits down to three — and hit #1 lands on a Starbucks at Central Park South (59th & Broadway branch), with its address, opening hours and latitude/longitude sitting right there in the raw tags. One coffee shop, surfaced out of 4.5 billion lines.

Three things worth noting:

Stages after the first are instant. They only scan the previous stage's context blocks, so the only real wait is the initial full-text search.
±N context is set per stage. Keep intermediate stages tight, then open the final stage up (the screenshot uses ±12) to actually read the story.
Every tab keeps the usual tools: jump to the source line, save results to a file — and a right-click History (drill-down path) menu shows exactly which hits led you here, line numbers included.

How this differs from klogg's Boolean search

klogg's and/or Boolean search works within a single line. Drill-down finds co-occurrence across nearby lines — and in real logs, the clues are almost never on one line.

The same tabbed UI is also gaining Sequence Search — detecting "w1 → w2 → w3 in that order," the desktop equivalent of Elastic EQL's sequence or Splunk's transaction. Almost nothing offers that against a multi-gigabyte local file. More on that soon.

Get it

Drill-down Search ships in UwView Pro V1.3 — released and available now. The free edition keeps the classic single-stage search with ±1 context and result export.

UwView Pro V1.3 is available on Polar. The monthly subscription comes with the first month free (the one-time purchase has no free trial).

Buy UwView Pro (Polar — one-time $129 / $9 per month, first month free): https://buy.polar.sh/polar_cl_37MuoKb8WjSfLZ7hhjaTTzwAVBxu2XyqbnuWe3aGzbj
UwView Pro product page: https://uvp.y42u.net/en/pro-en/
Free UwView: https://github.com/amru195704/UwView

A klogg Alternative, Benchmarked — open a 50 GB log and reopen it in 0.05 s

I Benchmarked My Free Viewer Against EmEditor and klogg — Honestly

y4u — Mon, 24 Aug 2026 22:43:11 +0000

If you ask "which text editor handles huge files?", EmEditor is usually the first name. Rightly so — it officially opens files up to 16 TB. I build UwView, a viewer specialized in huge files, and I'd already benchmarked it against klogg (the OSS log viewer). Time to face the commercial heavyweight.

Same Windows laptop (16 GB RAM, internal SSD), same file: ~48 GB, ~892 million lines of OpenStreetMap Japan XML. Native x64 builds of both. Search term: "東京" (Tokyo).

Results

Task	EmEditor Pro 26.2.5	UwView Pro 1.2.2
Jump to end right after opening	not possible	possible
Whole file navigable after	4 min 06 s	immediately
Index building	246 s	74 s
Full-text search	160 s	12.5 s
Reopening the same file	~4 min again	instant (saved index)

Three observations:

"It opens" ≠ "you can work." EmEditor displayed the beginning promptly, but until loading hit 100% (4 min 06 s) you couldn't reach the end of the file. UwView also builds its index in the background — but the whole file is navigable before the index completes.
Search compounds. 160 s vs 12.5 s is ~2.5 minutes per search. Ten searches with different terms in one incident = ~24 minutes of difference, by simple arithmetic.
The second day is where the gap grows. EmEditor repeats the ~4-minute pass on every reopen. UwView Pro saves the index + compressed cache and reopens instantly.

Where I lose, in writing

EmEditor's editing features are overwhelming — CSV mode, sorting, macros, decades of accumulation. It's not realistic for UwView to compete on feature count, so I don't. In the klogg comparison I published the table of everywhere klogg won, too. Losing in public is cheaper than being caught overselling.

UwView competes on exactly one axis: the waiting time before you can start working on a huge file — view instantly, search fast, reopen instantly, archive at ~1/9 and open without unpacking.

Rich editing, CSV, macros → EmEditor
View and search a huge file right now, once → UwView (free)
Same huge files, repeatedly → UwView Pro (v1.3.0+; one license covers Windows/macOS/Linux, monthly plan has a one-month free period via Polar)

Full write-ups: vs EmEditor · vs klogg

Measurements from one PC, one file, the versions listed (EmEditor is a product of Emurasoft, Inc.). Your mileage will vary — please verify with your own data. Everything shown is included in UwView Pro v1.3.0+.

You Found the ERROR. The Cause Is in the Lines Before It

y4u — Mon, 24 Aug 2026 22:07:36 +0000

A real incident investigation starts the moment you find the ERROR line. The ERROR is the result — the cause is usually upstream. The WARN just above it, a timeout a few seconds earlier, a config load hundreds of lines back. If you can't see those, your report says "an error occurred" and nothing more.

Where grep's context flags stop helping

grep -B 20 -A 5 is a fine first step. Then:

The context width is a guess made in advance. If 20 lines wasn't enough, run it again
The extracted fragment is a different text — there's no way back to the original position when you want to go 2,000 more lines upstream
With thousands of hits, you're now investigating your fragments instead of your log

What the job actually needs: a hit list and the original file, side by side, staying in sync.

A live demo: 4.5 billion lines → one coffee shop, in 3 steps

To show what drill-down search feels like, here's a real run — not on a log, but on something bigger: the entire US OpenStreetMap expanded to one XML file (258 GB, 4,509,830,821 lines), opened directly from its compressed .uwvz archive without unpacking.

New York → 100,492 hits in 30.28 s
Drill down: Central Park → 226 hits
Drill down again: coffee_shop → 3 hits

Hit #1 lands on a Starbucks at Central Park South — opening hours, address, payment methods, latitude/longitude, all in the raw tags, with ±12 lines of context shown around the hit. A right-click shows History (drill-down path): the exact three steps that got you there, each with its line number.

Swap the words and this is exactly an incident investigation: ERROR → payment service → one request ID. From millions of lines to the one thread that matters, and the path is recorded.

There are two multi-stage modes, and the difference matters for logs. Drill-down narrows within the previous hits (100,492 → 226 → 3 above). Sequence finds the terms in order of appearance in the file — same three words gave 100,492 → 2,798 → 1,246 chains, each linking occurrences thousands of lines apart. On a map file that's a curiosity; on a log it's exactly how you trace causality: deploy finished → timeout → ERROR, in that order, however far apart the lines are.

The workflow (free)

In UwView, search results open in an independent popup window:

Open the log (multi-GB is fine — readable the moment it opens), search ERROR
Double-click a hit → the main view jumps to that line and highlights it. The popup stays open, so you bounce list → scene → list as often as you need
At the scene, just scroll upward. 20 lines or 20,000 — the context never gets cut off, because you're in the original file
In the popup, turn on ±1-line context to skim every hit with the line before it. If the same WARN precedes every ERROR, you'll see it here
Found a suspect? Search again for the request ID / thread ID and follow that one thread through time
Save… writes the hits (optionally with surrounding lines) to a file — ready to attach to the report

Add color rules (ERROR red, WARN yellow) and the pattern "yellow gets denser before the accident" becomes visible while scrolling.

Free vs Pro, honestly

The whole investigation above is covered by the free edition — jump, save, and ±1-line context included.

UwView Pro (v1.3.0+) raises three ceilings for repeat work: context up to ±64 lines, an independent popup per tab (line up an app log and a DB log, cross-check their ERROR lists), and instant reopen from a saved index (~0.02–0.07 s measured). One investigation: free is enough. Returning to the same logs daily: that's Pro territory.

Full article: tracing context in a huge log. Source: GitHub.

"File Too Large to Open" — Investigating a 50 GB Log Without Splitting It

y4u — Mon, 24 Aug 2026 21:53:37 +0000

Someone hands you a log for an incident investigation — and it's 10 GB, sometimes 50 GB. Double-clicking does nothing. Your editor freezes. The investigation stops before it starts.

Why editors give up

Notepad dies at a few hundred MB. VS Code and Notepad++ freeze or drop into a restricted mode at a few GB. The reason is structural: an editor loads the whole file into memory so you can edit it. A 50 GB log will never fit in 32 GB of RAM. This isn't a bug you can configure away — it's what editing requires.

Why "just split it" backfires

The standard advice is split -b 1G. In a real investigation, it makes things worse:

Line numbers are gone — you can't report "the error is on line N" anymore
Context is severed — what happened right before the error now lives at the tail of a different file
50 GB = 50 files to open one by one. Search becomes manual labor again

What you need is not fragments. It's one log, viewable as one log.

The workflow (free)

UwView is a free viewer for huge text files (Windows / macOS / Linux). It can't edit — in exchange, it starts displaying before the file is fully read.

Download (Windows: unzip and run, no installer)
Drag & drop the log
Scroll immediately. Drag the scrollbar to the bottom — you're at the newest entries
Search "ERROR" from the toolbar (regex supported)
Jump to a hit from the results list, read the surrounding lines in place

Indexing runs in the background; line numbers appear when it's done. You don't wait for it.

One measured data point: a 47.73 GB, ~892-million-line file (OSM data, USB SSD, 32 GB-RAM machine) — scrolling to the end and searching worked immediately after opening. The line-count ceiling is ~550 billion lines; in practice your disk runs out first.

Honest scope note

A one-off investigation — open once, find the error, read the context — is fully covered by the free edition, including regex, color rules, and encoding auto-detection (CJK included).

Two waits remain in the free edition: the index is rebuilt on every reopen, and every search reads the file itself. If you keep returning to the same logs, UwView Pro (v1.3.0+) saves the index and a compressed cache: reopen in ~0.02–0.07 s, search ~9× faster, and archive at ~1/9 size that opens without unpacking. For a one-time job, the free edition is enough — that's the honest split.

Full walkthrough: the original article. Source: GitHub.

Figures are measurements in one environment and will vary.

My Fanless Mac Skewed My Benchmark by 54% — Thermal Throttling and Round-Robin Measurement

y4u — Fri, 14 Aug 2026 13:41:36 +0000

While measuring how my search engine scales with thread count (results in the companion article, I threw away my entire first data set. Here's why — and if you ever benchmark anything on a fanless laptop, this is not someone else's problem.

The first data set was clean, and wrong

I measured 1 through 10 threads, in order. The curve looked beautiful, including a shiny record: "11 threads, fastest at 5.2 seconds." Right before writing the article, I re-ran the same conditions as a sanity check.

The same conditions came back up to 54% different. 4 threads: 11.0s became 9.0s. 11 threads: 5.2s became 8.0s. The record run did not reproduce.

No rogue background process. The culprit was the chassis.

The culprit: thermal history on a fanless machine

The test machine is a MacBook Air (Apple M4) — fanless. Under sustained load it heats up and thermal-throttles. Which means: every measurement depends on what you measured just before it.

The nasty part is that this is not random noise — it's a systematic error. Sweep 1→2→...→10 in order and the later thread counts always run on a hotter chip. The high-thread results are penalized, consistently, in the same direction. Averaging repeated sweeps doesn't remove it, because the bias repeats too. That "fastest 5.2s at 11 threads"? A single lucky run on a cold chip. The cleaner the graph, the more suspicious you should be.

The fix: round-robin

Stop measuring each thread count in a block. Instead: sweep 1-16 threads once, repeat the whole sweep for 4 rounds, and take the per-thread-count median across rounds. Every thread count now experiences cold and hot states equally; the thermal history no longer piles onto specific configurations.

The corrected protocol (128 measurements) produced the companion article's conclusion: a plateau at 8 threads, 3.0x. The 5.2s ghost vanished; 7.4s became a reproducible floor.

How do you know the fix worked?

Claiming "the new numbers are right" needs evidence. Mine: two search patterns with hit counts differing by more than an order of magnitude (10,967 vs. 722 hits) produced nearly identical scaling curves. If heat or any other disturbance were still leaking in, there's no reason two independent series would line up that well.

I kept the first CSV for reference but decided it never appears in an article. Publish a retracted number "for reference" and someday someone will cite it.

Lessons

On a fanless machine, measurement order leaks into results. A sequential sweep systematically penalizes the later configurations
Distrust beautiful single records. One cold run masquerades as a best case
Round-robin + median distributes cold and hot fairly across all configurations
Validate with independent series, not repetition. Re-running the same biased protocol reproduces the same bias

The benchmark's enemy wasn't a rival product. It was my own chassis.

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

A note
The information in this article is provided for reference purposes only, and its accuracy or completeness is not guaranteed. If you notice any errors or inaccuracies, please let us know in the comments and we will review and correct them.

How Many Search Threads Is the Right Number? I Measured 0.89 Billion Lines at 1-16 Threads

y4u — Fri, 14 Aug 2026 13:30:46 +0000

When you parallelize a text search, how many threads should you use? "One per core," "cores x 2," "physical cores only" — the folklore varies. The only number I trust is one measured on my own app, against real data.

I benchmarked the search engine of UwView Pro, my large-text viewer, against 0.89 billion lines of real data at 1-16 threads. The headline: it plateaus at 8 threads (3.0x over single-threaded) — on a 10-core machine.

The full methodology

Machine: MacBook Air (Apple M4 / 10 cores = 4 performance + 6 efficiency / 32GB RAM / on AC power)
Data: OpenStreetMap Japan japan-latest.osm (48GB original, 0.89B lines) as a 5.3GB compressed .uwvz cache
Target: the search engine run standalone (search-standalone) — no UI, no file-open cost
Condition: warm cache. Cold-cache numbers were not measured this time
Protocol: a 1-to-16-thread sweep repeated for 4 rounds (round-robin), taking the per-thread-count median across rounds — 128 measurements total

Why round-robin instead of "measure 1, then 2, then 3..."? The M4 Air is fanless. Under sustained load it thermal-throttles, so measurement order leaks into the results as a systematic error: a sequential sweep measures the later thread counts on a hotter chip. That story deserved its own post (see the companion article); every number below is from the corrected protocol.

The harness is a single shell script driving the engine and dumping CSV; a Python script draws the plots.

Results

Two search patterns with very different hit counts:

Threads	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
`Tokyo` (10,967 hits)	22.2	13.8	11.5	10.2	9.2	8.6	7.8	7.4	7.4	7.4	7.8	8.0	7.9	7.9	7.6	7.5
`Kamakura` (722 hits)	22.2	13.6	11.9	10.2	9.1	8.4	7.6	7.4	7.6	7.5	8.0	8.2	7.9	8.0	7.8	7.6

Three facts worth a headline

1. It plateaus at 8 threads: 22.2s single-threaded down to 7.4s (3.0x). From there to 16 threads it stays flat at 7.4-8.2s. More threads don't help — but notably, oversubscription up to 16 didn't visibly hurt either.

2. The plateau is not "the core count." This machine has 4 performance + 6 efficiency cores, 10 total. The plateau lands at 8 — short of all 10 cores, well past the 4 P-cores. Neither core type alone explains it. Apply the "threads = cores" folklore here and you'd pick 10 (same speed as 8, so no harm, no gain); pick 4 and you're at 10.2s — 27% slower.

3. Hit count doesn't matter. With hit counts differing by more than an order of magnitude (10,967 vs. 722), the two curves match almost perfectly. The work is dominated by how much you scan, not how much you find.

One finer observation: the scaling is sublinear from the start — 1.6x at 2 threads against an ideal 2x. The overhead and memory-bandwidth contention begin with the second thread, not the ninth.

Honest limitations

All numbers are warm-cache; cold was not measured
One machine only (MacBook Air M4); a CPU/RAM matrix is a separate planned experiment
Nothing beyond 16 threads was measured

What this means for the product: automatic

What the data says: on this machine and workload, ~8 threads is the sweet spot, and missing it in either direction costs you. And the sweet spot will move from machine to machine. A "number of threads" setting in the UI would mostly be a device for users to pick the wrong value.

So UwView Pro chooses the thread count automatically (UWV_SHARDS=auto is the default). You configure nothing. This benchmark existed to decide what "auto" should do.

If you regularly search huge logs or datasets, give UwView Pro a look — persistent index, compressed-cache search, and ~1/9 storage make both reopening and searching a step faster (all OS, $129 one-time / $9 per month).

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

A note
The information in this article is provided for reference purposes only, and its accuracy or completeness is not guaranteed. If you notice any errors or inaccuracies, please let us know in the comments and we will review and correct them.

Reading Huge Logs by Color — a Highlighter That Doesn't Stutter at 100 Million Lines

y4u — Tue, 11 Aug 2026 13:45:34 +0000

In v1.1 of UwView, my large-file text viewer (free, source on GitHub), I implemented a color highlighter. When I honestly compared features with the industry-standard klogg, "multi-keyword color highlighting" was a clear item on my loss list — something klogg had that UwView didn't. This release fills in that line on the scoreboard.

And it didn't stop at catching up. UwView ships with use-case presets built in from the start, and also supports exporting/importing rule sets. This article walks through what you can now do — and the design choices that keep coloring smooth even on a 100-million-line file.

For testing I used an XML file with 100,000,000 lines converted from OpenStreetMap Japan data.

Search's "Yellow" and Highlighting's "Red/Blue" Work Together at the Same Time

The basic layout: body text on the left, search-results (filter) popup on the right. A search for "Wakayama" hit 1,129 matches, listed with ±1 line of surrounding context.

The point to notice is that the yellow of the search match and the red applied by the color highlighter both appear on the same screen at the same time. UwView's highlighter is designed so that search matches are always drawn with top priority — no matter how many colors you stack, the yellow of the term you're currently searching for always stays on top. This avoids the common failure mode of this kind of feature, where too much coloring buries the search results.

One more understated bit of engineering: coloring is evaluated only for the lines currently visible on screen, each time. That's why, even with a 100-million-line file, the coloring never falls behind while scrolling.

Color Rules Are Built from Patterns and Background Colors

Coloring is managed in a dedicated "Color Highlighter" dialog. Each line is one rule, assigning a text color and a background color to a pattern (a literal string or a regular expression).

Regular expression support — you can also color just the captured portion of a match.
Case sensitivity (Aa) and whether to highlight the whole line can be set per rule.
Rules are prioritized top to bottom. When rules overlap, the lower row wins; reorder with ▲▼.
Too many colors makes things harder to distinguish — aim for around 8 to 12 colors per screen. Colors come from a color-vision-friendly 32-color palette and cycle automatically as you add rules.

You can save a rule set under a name, so you can switch between them per project or per system you're monitoring.

Bundled Presets for "syslog" and "Web Access Logs"

This is the part that goes beyond simply catching up with klogg. UwView v1.1 ships with commonly used coloring rules built in. Pick a preset, click "Load," and the colors apply on the spot.

The syslog / Linux preset colors emerg / alert / crit / err red, warning orange, notice / info green, and also assigns colors to the PID at the start of a line ([number]) and to IP addresses.

The Web access (HTTP) preset lets you read HTTP status codes by color: 5xx red, 4xx orange, 3xx blue, 2xx green — clusters of errors jump out at you just from skimming an access log.

These presets can be used as-is or rewritten to your own taste. A finished rule set exports as a .uwvhl file and can be shared with another machine or a teammate via import — you can hand out "site-specific coloring configurations" to everyone who needs them.

Search History and Predefined Filters Also Improved

Alongside coloring, v1.1 raises the bar around search: up to 50 history entries with autocomplete, and starred (★) searches saved for instant reuse from a dropdown. This too fills an area where klogg previously had the edge.

The items still remaining on my loss list stay published openly in the repository. The policy of laying everything out honestly and filling gaps one by one is unchanged.

One thing I'm particular about, though: even when adding a feature I was behind on, I don't copy klogg's implementation — I redesign it into a form that feels good to use every day before shipping it. The color highlighter is exactly that: not just "you can apply colors," but "the search yellow stays on top at all times," "presets bundled for common use cases," and "only visible lines are evaluated, so speed never drops at 100 million lines" — the things you actually want once you're working with genuinely huge logs.

Summary

UwView v1.1 implements a color highlighter, filling in one line on the list of items where klogg had the edge.
Supports regular expressions, text/background colors, rule priority, and named saves. Search-match yellow always stays on top, and coloring stays fast even at 100 million lines.
Ships with presets for syslog, web access logs, and more; rule sets are shareable as .uwvhl files via export/import.
Search history and predefined filters also improved. Remaining gaps stay listed openly, to be filled in a form that's genuinely comfortable to use — not by copying klogg.

The commercial UwView Pro is also on sale (all OS: Windows/macOS/Linux; one-time $129 / $9 per month) — persistent index for instant reopens with line numbers, search up to ~9x faster, and ~1/9-size archival storage that opens directly. The color highlighter and presets covered here work the same way in Pro.

Sources

klogg official documentation https://github.com/variar/klogg/blob/master/DOCUMENTATION.md
amru195704/UwView (GitHub) https://github.com/amru195704/UwView

From the developer: a list of my apps, Kindle books and open-source projects is on GitHub: amru195704. Screenshots of everything described here are in the original article.

I Rebuilt My 30-Year-Old Text Viewer in C#/Avalonia — It Matched the Industry-Standard klogg. Then I Redesigned It for Today's Hardware.

y4u — Sat, 08 Aug 2026 13:36:13 +0000

The design of my large-file text viewer UwView traces back to the old UwView I distributed on Vector back in the Windows 95 era — 30 years ago. I rebuilt it from scratch in C#/Avalonia, and released a premium edition, UwView Pro (Windows/macOS/Linux; one-time $129 or $9/month; product page https://uvp.y42u.net/en/pro-en/). Now that I have solid measurements from the core engine, here's a serious head-to-head against klogg, the industry-standard viewer for huge log files.

Cutting straight to the conclusion: when actually measured, klogg and the current (free) UwView performed at roughly the same level. In other words — isn't the "industry standard" older than you'd expect? This article is about that, and about what happened when I redesigned that same architecture from scratch for today's hardware.

Test conditions — a real 48GB file, 892,239,125 lines

All benchmarks were run under identical conditions on the identical file.

Target file: OSM data for all of Japan, japan-latest.osm (47.73GB, 892,239,125 lines — the same real-world data used in my earlier 51GB experiment)

Note on file size notation: the "48GB" figure here is 47.73GiB (bytes ÷ 1024³), rounded. macOS's own size display (SI units, ÷1000³) shows 51.25GB. Both refer to the same file (51,254,526,392 bytes).

Environment: 10-core Mac, 32GB RAM, external USB drive (measured physical throughput 0.41GB/s)
Comparison target: klogg 24.11.0 (main search always uses the regex engine, Match case ON)
Search hit counts were confirmed to match exactly across all patterns among klogg, UwView, and UwView Pro (e.g., literal "Tokyo" = 10,967 hits)

Round 1: klogg vs. current UwView — nearly identical

Item	klogg 24.11	UwView (public release)
First open (index build)	About 110 seconds	128–186 seconds
Every subsequent open	Every time, about 110 seconds (re-indexes)	Every time, 128–186 seconds (rebuilds)
Search literal "Tokyo"	120–135 seconds	156.2 seconds

There's some variance in the numbers, but it's clear that both tools are built on the same principle: "read the entire 48GB raw file, every single time." Both hover around 0.3GB/s throughput — meaning both are pinned to the physical bandwidth ceiling of the disk. That's not a matter of which tool is better; it's a matter of which design generation each belongs to.

To be clear, I did not look at klogg's source code at all. This is an inference based purely on external measurements hitting the same physical ceiling, but the underlying structure — rebuilding the index every time you open the file, and scanning the raw file every time you search — appears to belong to the same design generation.

And current UwView's design originates from the old UwView of 30 years ago. The first discovery from this comparison: the industry-standard klogg performs on par with a 30-year-old design.

One point where it isn't even "on par"

One feature the old UwView has had consistently since 30 years ago is that "the entire file is visible the moment you open it" (progressive open). Current UwView also lets you jump freely to the middle or end of the file even while the index is still being built.

What about klogg? During my measurements, I confirmed that only the beginning of the file is visible until index building finishes (you cannot scroll to the middle or end). For a 48GB file, that's roughly 110 seconds during which the end of the file is simply off-limits. On this one point, klogg doesn't even match the 30-year-old design — it falls short of it.

Round 2: Enter UwView Pro — a design rebuilt for "now"

What's changed between 30 years ago and today? RAM in the tens of gigabytes is now standard, CPUs commonly have 10 cores, and compression like zstd — "compression faster than the disk itself" — is now available. UwView Pro's engine was redesigned from the ground up around these assumptions.

At the core is a sidecar approach. Three key points:

On the first open, a zstd-compressed cache is generated at the same time the index is built (compression happens on otherwise-idle CPU cycles between disk reads, so it adds essentially zero extra wait time)
From the second open onward, only the saved index needs to be read (milliseconds). Searches read the 5.3GB compressed cache instead of the 48GB raw file (a 1/9 reduction in bytes read)
The compressed cache preserves every byte of the original file losslessly, with block-level checksums. Even if you delete the original file and keep only the 1/9-sized cache, you can still open and search it directly

Overall comparison table — measured results

Item	klogg 24.11	UwView (public release)	UwView Pro (on sale)	Pro ÷ klogg
First open	~110 s (only the beginning visible until complete)	128–186 s (entire file visible immediately)	140 s (includes index + compressed cache; entire file visible immediately)	About the same
Every subsequent open	~110 s every time	128–186 s every time	0.02–0.07 s	1,500x or more
Search literal "Tokyo"	120–135 s	156.2 s	14.3 s	About 9x
Search case-insensitive "Tokyo"	~120 s	(not measured)	14.0 s	About 8.6x
Search regex "Tok[yi]o"	~130 s	(not measured)	29.8 s	About 4.4x
Search regex "name:en.*Tokyo"	~130 s	(not measured)	29.2 s	About 4.4x
Disk footprint (archival use)	48GB (original required)	48GB (original required)	5.3GB (original deletable; checksum-protected)	1/9

An honest note

Instant to view from the very first open. UwView lets you read, scroll and search the entire text the moment you open it (klogg shows only the head until indexing finishes). The index and compressed cache are built on the first open, in the background (about 140 s for 48GB — bound by reading the raw file once at 0.41GB/s; you can browse while it runs). Because indexing happens on the first open, from the second open on it's instant, with line numbers (0.02–0.07 s).
All figures above are measurements from a single real-world environment. RAM capacity, storage speed, and file contents will all affect the numbers.

Current status

The engine (parallel index building, parallel search, and the sidecar mechanism) is fully implemented, and every figure above comes from measurements of working code. UwView Pro is on sale now (Windows/macOS/Linux; one-time $129 or $9/month). → https://uvp.y42u.net/en/pro-en/

Current UwView (free) remains available on GitHub. Give the "entire file visible the moment you open it" experience a try — it's been a core part of UwView for 30 years.

Summary

Measured head-to-head, the industry-standard klogg and current UwView (built on a 30-year-old design) perform at roughly the same level — both belong to the "read the entire raw file every time" generation.
On "the entire file is visible the moment you open it," klogg doesn't even match the 30-year-old UwView (only the head is visible until indexing completes).
UwView Pro is a next-generation engine redesigned for today's hardware (abundant RAM, multi-core CPUs, compression faster than disk). Measured on 48GB / 892M lines: 1,500x+ for subsequent opens, ~9x for search, 1/9 the storage.
UwView Pro is on sale now (Windows/macOS/Linux; one-time $129 or $9/month). → https://uvp.y42u.net/en/pro-en/

Sources

amru195704/UwView (GitHub) https://github.com/amru195704/UwView
klogg (GitHub) https://github.com/variar/klogg
OpenStreetMap data (Geofabrik: japan-latest.osm) https://download.geofabrik.de/asia/japan.html
Zstandard (zstd) https://github.com/facebook/zstd

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

DEV Community: y4u

How to Open a 50GB Log File — and Reopen It in 0.05 Seconds. A klogg Alternative, Benchmarked

The test

The numbers

Why the difference exists

One more thing: you can move around while it indexes

When you should stay with klogg

When UwView Pro makes sense

What about the other klogg alternatives?

Free version vs Pro

Update (Aug 26, 2026): the search gap has since reversed

Further reading

[In Development] Editing a 48GB File and Saving Mid-Way: EmEditor vs UwEditor Pro

Results first

Where this comparison applies — below ~10GB, EmEditor is faster

Test environment

1. Opening — a tie

2. Search — 245.3 s becomes 23.9 s

Part of this gap is thread count

3. Replace — 257 s becomes 35.9 s

4. Mid-work saving — the question of whether you can stop

"0 seconds" here means the mid-work save

5. Final write-out — 31 minutes becomes 1 min 33 s

What happens when you come back the next day

Day 1 — open, search & replace, save

Day 2 — reopen the same file, finish the edit, write it out

What these two tables show

Being straight about the limits

How it relates to UwView Pro

[In Development] I Replaced 21,994 Occurrences in a 10GB, 100-Million-Line File in 16.8 Seconds

The file

1. Open it

2. Enter edit mode

3. Count what you are about to change

4. Replace all

Why 21,948 and 21,994 disagree

5. Run it

6. Verify

7. Now look at the file sizes

Why it works this way

Being straight about the limits

How it relates to UwView Pro

Find Only Where 'New York Central Park coffee_shop' Appear in That Order — Sequence Search on a 258 GB Local File

What does searching by "order" mean?

Real example: 1,246 "New York → Central Park → coffee_shop" flows in 4.5 billion lines

The path itself is visible — the History menu

Speed

Get it

Related

From 100,492 Hits to 3 in Two Clicks — Drill-down Search for Huge Local Files

It's the grep pipeline you already type every day

Real example: finding one coffee shop in 258 GB / 4.5 billion lines

How this differs from klogg's Boolean search

Get it

Related

I Benchmarked My Free Viewer Against EmEditor and klogg — Honestly

Results

Where I lose, in writing

You Found the ERROR. The Cause Is in the Lines Before It

Where grep's context flags stop helping

A live demo: 4.5 billion lines → one coffee shop, in 3 steps

The workflow (free)

Free vs Pro, honestly

"File Too Large to Open" — Investigating a 50 GB Log Without Splitting It

Why editors give up

Why "just split it" backfires

The workflow (free)

Honest scope note

My Fanless Mac Skewed My Benchmark by 54% — Thermal Throttling and Round-Robin Measurement

The first data set was clean, and wrong

The culprit: thermal history on a fanless machine

The fix: round-robin

How do you know the fix worked?

Lessons

How Many Search Threads Is the Right Number? I Measured 0.89 Billion Lines at 1-16 Threads

The full methodology

Results

Three facts worth a headline

Honest limitations

What this means for the product: automatic