DEV Community: y4u

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.

Shelve an Investigated Log at 1/9th the Size, Reopen It Tomorrow Right Where You Left Off

y4u — Wed, 05 Aug 2026 13:59:29 +0000

In We Released UwView Pro, I introduced the Archive feature (store at roughly 1/9th the size and view without unpacking) and Session Restore, added in Ver1.1.1 (reopen the app and pick up right where you left off), as two separate features. This time, let's walk through what happens when you connect these two into a single investigation workflow, with concrete steps.

The Scenario — "I Want to Wrap Up Today's Investigation, but I Might Look at It Again Tomorrow"

A common situation in incident investigation or log review is: "I want to reach a stopping point today, but I can't say the investigation is completely finished." A log file in this state creates a bind:

Too early to delete it (you might need to look at it again)
Too heavy to just leave as-is (multiple 48GB-class logs piling up on your desk)
Leaving the tab open indefinitely isn't realistic either (you want to restart your PC for other work)

This is exactly the dilemma described in "To Delete or Not to Delete".

Workflow 1: "Shelve It" Before Finishing the Investigation

Once you've finished a round of searching, color-coding, and bookmarking, run Archive from the File menu.
The original file's contents are compressed with a checksum into an indexed archive with a .uwvz extension. In my measurement, a 48GB log came down to roughly 5.3GB (see the benchmark article for details).
Once you've confirmed the archive was created, you can delete the original 48GB file. The .uwvz file can be opened and searched directly, without unpacking.

At this point, your desk (disk) has shrunk from 48GB to 5.3GB, and you're still ready to respond instantly if you need to look at it again.

Workflow 2: Pause Work While Leaving Tabs Open

There are also logs where you're not ready to commit to archiving yet — you're still actively working on them. This is where Ver1.1.1's Session Restore comes in.

Even if you quit the app or restart your PC with multiple logs open in tabs, the tabs you had open are restored exactly as they were the next time you launch the app.
For large logs, if the index still lives with the regular file rather than in a .uwvz, reopening rebuilds the index on that open, in the background (you can browse while it runs) — but your search conditions, color-coding rules, and bookmark positions are all preserved regardless.

Session Restore's role is this: even if you close your laptop after saying "that's it for today," you can resume exactly where you left off the next morning without any hesitation.

When to Use Workflow 1 vs. Workflow 2

State	Feature to Use	Effect
Investigation done, but can't delete yet	Archive (`.uwvz`)	Compresses disk usage to roughly 1/9th, reviewable without unpacking
Investigation ongoing, pausing for today	Session Restore	Carries tabs, search state, color-coding, and bookmarks over to next time
Investigation done and unlikely to continue	Archive → Delete	Minimizes disk usage in the end

In practice, you'll often use these two in sequence: keep working with Session Restore maintaining your tabs for the time being, then drop into Archive once you reach a natural break point. Even a .uwvz archive that's been reopened is treated as a regular tab just like an ordinary log file, so it's still subject to Session Restore.

Why This Combination Works

The free version of UwView is focused on opening huge files; the Pro version handles the operational side of things after the file is open. Archive covers "storage" and Session Restore covers "continuity of work" — because these two responsibilities are cleanly separated, the full arc from "end of one day" to "resuming the next morning" — something hard to see when each feature is explained on its own — only comes into focus once you combine them.

Summary

For logs you've finished investigating but can't delete yet, shelve them with Archive (roughly 1/9th the size, checksummed, no unpacking needed)
For work still in progress, carry your tabs, search state, and color-coding forward with Session Restore
The realistic situation of "I'm done for today, but I might look at this again tomorrow" is covered by combining these two features

And if a huge log is eating your disk and you want it compressed for storage while staying searchable at speed, 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). The free version is available on GitHub.

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

I Expanded the Entire US OpenStreetMap to a Single 258 GB XML File — 4,509,830,821 Lines, and What Broke

y4u — Sat, 01 Aug 2026 11:40:31 +0000

A few days ago I benchmarked the native and browser builds of my viewer against a 3.16 GB, 100-million-line XML file carved out of Japan. The whole time I kept thinking the same thing: at 100 million lines, this thing still isn't trying.

UwView is built around one claim — "open any huge file, instantly readable and searchable." If you're going to say that out loud, you owe it to yourself to find out where it breaks. So I went and got the OpenStreetMap data for the entire United States.

Making the test file

Genuinely huge files are surprisingly hard to come by. Logs get rotated. Dumps get chunked. An unsplit, near-terabyte single file is something you basically have to manufacture yourself.

So I took the Geofabrik extract for the whole US (PBF, about 11 GB) and expanded it to XML with osmium cat. About 15 minutes later:

us-260726.osm
258,679,440,228 bytes  =  258.68 GB (240.9 GiB)

ls -lh reports 241G — same file, GiB spelling. One XML document. No splitting.

The numbers

Measured on real macOS hardware with UwView Pro, stopwatch-timed from the UI at second-level precision.

Item	Measured	Conditions
First open (until indexing completes)	5 min 28 s (328 s)	full scan of 258.68 GB ≈ 789 MB/s
Second open onward	instant	`.uwvz` sidecar (Pro feature)
Total lines	4,509,830,821	determined once indexing finished
Search "New York"	34.8 s / 100,492 hits	after indexing
Search "Boston"	~34 s	after indexing
`.uwvz` sidecar size	28.61 GB (28,608,409,551 B)	~11% of the original

The line count broke `int`

4,509,830,821  >  2,147,483,647

This is the part I want to put in front of anyone who has ever written a text viewer, a log parser, or an indexer. 4.5 billion lines does not fit in a signed 32-bit integer. Not the offsets — those obviously need 64-bit at this size — the line numbers themselves.

If line numbers are int anywhere in the pipeline, this file doesn't produce an error. It produces a negative line number, silently, somewhere past line 2,147,483,647, and every jump and every search result after that point is garbage. UwView carries line numbers as long throughout, which until this test was a design decision I had never actually needed. Now I have the receipt.

You can read the file while the index is still building

This is the screen I most want to show, and the reason I bothered building the file at all. (Screenshots are in the full write-up.)

The tab reads us-260726.osm 10%, the status bar shows an indexing progress bar with a cancel button — and the body is already displaying real <relation> and <member type="way" ref="..."/> elements, and it scrolls.

That's page-mode instant open: the file is never loaded, only the visible window is read and painted. So at 258.68 GB content appears the moment you pick the file. Indexing runs behind it, and line numbers appear when it finishes.

Most viewers show you the head of the file and nothing else until indexing completes. For 5 minutes and 28 seconds, do you stare at page one, or do you start reading? That gap matters most precisely when you are in trouble at 3 a.m.

The line-number gutter is empty at this stage. Line numbers arrive after indexing — by design, and I'd rather say it than hide it.

Search time is bound by data scanned, not hits found

The most interesting result was search.

"New York" returned 100,492 hits in 34.8 seconds, listed in the filter results window with line numbers and ±1 line of context — things like <tag k="operator" v="New York City Transit Authority"/>. Very much OSM.

"Boston" took about 34 seconds. Wildly different hit counts, essentially identical time.

So full-text search here is bound by how much data it scans, not how many matches it finds. That's a quietly useful property in practice: you never have to guess whether a rare word will be fast or a common word slow. Knowing that any word costs about 34 seconds is enough to decide whether you have time to go make coffee.

258.68 GB ÷ 34 s works out to about 7.6 GB/s, but that is a nominal figure, and I want to be explicit about it: Pro's search reads through the saved compressed cache (28.61 GB), so the bytes actually touched are far fewer. This is not a claim that an SSD hit 7.6 GB/s.

The sidecar is 11% of the original

On first open, UwView Pro writes the index plus compressed data into a .uwvz sidecar. Here it landed at 28.61 GB — about 11% of 258.68 GB, roughly 1/9.

That 28.61 GB is what turns 5 min 28 s into zero on every subsequent open. And 11% is also a storage story: instead of keeping the 258.68 GB XML around, keep the sidecar and open and search that directly when you need it.

Honest notes

All figures are from one machine, one file, one run each. Different hardware and storage will give different numbers.
The 5 min 28 s first open cannot be shortened. 258.68 GB has to be read through once. The claim was never "fastest first open" — it's that you can read during it, and every open after that is instant with line numbers.
Search needs the index. Browsing works while indexing runs; full-text search waits for it to finish.
The instant second open is a Pro feature. Free UwView doesn't persist a sidecar, so it rebuilds the index in the background each time — browsing and searching from the first open work the same.
"≈789 MB/s" and "≈7.6 GB/s" are derived (size ÷ elapsed), not storage benchmarks.

Summary

Testing at a size nobody meets in real work wasn't about bragging. It was about finding out whether the design claims survive contact with it:

At 10% indexed, the whole file was already browsable and scrollable
4,509,830,821 lines, and jumping to the end was instantaneous
Search cost ~34 s regardless of the word, and 100k+ hits came back with context
A 28.61 GB sidecar (~11%) made every reopen instant
And the line count itself proved why long was never optional

Near a terabyte, I didn't have to change how I say it.

UwView is free and cross-platform (Windows / macOS / Linux, plus a WASM build). If you work with big logs or dumps, throw it at the largest file you own — and if it breaks, please tell me. That's the useful part.

Full write-up & screenshots (original): https://uvp.y42u.net/en/blog/uwview-osm-usa-258gb-en/
Source / roadmap: https://github.com/amru195704/UwView
Product ($129 one-time / $9 per month, cross-platform): https://uvp.y42u.net/en/pro-en/

Data: © OpenStreetMap contributors, ODbL — https://www.openstreetmap.org/copyright

Why We Split Search Results Into a Separate Window — Jump, Save, and Context Lines You Can Use \"While Looking\" With the Filter Popup

y4u — Mon, 27 Jul 2026 02:27:20 +0000

We've moved UwView / UwView Pro's (UVF / UVP) search and filter results out of the inline, overwrite-the-main-view display and into an independent popup window. It sounds like a small change, but it fixes the one thing that kept getting in the way when reading huge logs: not being able to jump back to the original position while still looking at your results.

What Changed

Until now, filtering replaced the main text view in place, showing only the lines that matched your search. You could see the list of hits, but you couldn't check the surrounding context in the original file or look at another part of the file at the same time.

Now that filter results live in a non-modal, separate window, three things are possible at once.

1. Jump — go from the result list straight to the matching line in the document

Double-click (or press Enter on) a hit in the popup, and the main view scrolls to that exact line and briefly highlights it. The popup stays open the whole time, so you can go back and forth between the result list and the document body as many times as you like.

2. Save — export the filtered results to a separate file

The "Save…" button in the toolbar lets you export the filtered results as their own file. You can combine "body text only / line numbers + body text" with "hits only / include surrounding context," and the export streams line by line instead of loading everything into memory, with progress and cancel support. Even on logs with millions of matching lines, saving won't freeze the app.

3. Context lines (±N) — see what the hit line alone doesn't tell you

You can specify how many lines before and after each hit to show alongside it. When the context ranges of two nearby hits overlap or touch, they're automatically merged into a single block so lines never appear twice (for example, if lines 100 and 103 both match and you're showing 2 lines of context, lines 98–105 are shown as one merged block).

Free vs. Pro

We revisited how much of this to open up in the free version while building it. We originally planned to keep context-line display Pro-only, but ended up prioritizing the user experience and opening it up to the free version too, with a cap.

Feature	UwView (Free)	UwView Pro
Popup window	Yes (one window, follows the active tab)	Yes (a separate window per tab)
Jump & Save	Yes	Yes
Context lines (±N)	Yes (N = 0 or 1 only)	Yes (N up to 64)
Rectangle selection inside the popup	No	Yes

The free version caps context display at the hit line plus one line before and after (three lines max), while Pro lets you specify up to 64 lines of context. The free version's popup is always a single window that follows whichever tab is active, whereas Pro can keep an independent popup open per tab at the same time. Drag-based rectangle selection and saving inside the popup remain Pro-only.

Why We Kept "Save" in the Free Version

Exporting search results was originally floated as a possible Pro differentiator in our early product strategy. But partway through implementation, we decided that the bigger UX problem — not being able to get back to where you were while looking at your results — mattered more, so we kept Jump and Save in the free version. We shifted Pro's differentiation instead toward things that matter more for continuous, heavy-duty log operations: context lines up to 64, independent popups per tab, and rectangle selection.

Under the Hood (Briefly)

The display and the save path share the same logic. We built a single function that takes a set of hit lines and produces "blocks" that include N lines of context (with overlap merging), and both the on-screen view and the file export call that same function. On the display side, we use UI virtualization that lazily resolves rows block by block, so scrolling stays smooth even with millions of hits.

Summary

We moved filter/search results out of the inline, overwrite-the-main-view display and into an independent popup window
From the popup, you can now jump to the matching line in the document, save results to a separate file, and view ±N lines of context around each hit
The free version limits you to one popup and up to one line of context; UwView Pro adds an independent popup per tab, context lines up to 64, and rectangle selection
We prioritized the "use it while looking" experience by keeping Jump and Save free, and shifted Pro's differentiation toward more advanced operational features

If you want to search a huge log while still being able to move around the document, try this popup feature in UwView (free, open source). If you want independent popups per tab and rectangle selection on top of that, take a look at UwView Pro (all OS, $129 one-time / $9 per month).

Full write-up & images (original): https://uvp.y42u.net/en/blog/uwview-filter-popup-jump-save-context-en/
Source / roadmap: https://github.com/amru195704/UwView
Product ($129 one-time / $9 per month, cross-platform): https://uvp.y42u.net/en/pro-en/

How much slower is the browser build, really? — UwView native (UVF) vs WASM, measured on the same file

y4u — Mon, 27 Jul 2026 02:22:43 +0000

UwView, my large text-file viewer, runs both as a native desktop app (UVF) and in the browser (WASM) — same code, same feature set. Naturally, a different runtime means different speed. "It runs in the browser, so it must be slow, right?" To find out, I opened the exact same file in both and ran the same workflow, stopwatch in hand.

Test conditions

File: one chunk of the full-Japan OpenStreetMap extract, japan-dv-ah — about 3.16 GB / 100,000,000 lines of XML.
Same machine, same folder. Native UVF and browser WASM (served on localhost), driven in turn.
Workflow: open → full-text search for "東京" (Tokyo) → show ±1 lines of context → jump to the middle and end → close.
Timing is stopwatch-level (seconds). Hit counts were cross-checked between the two.

Results

Step	UVF (native, free)	WASM (browser)	Gap
Page-mode instant display (the moment you open)	instant	instant	equal
Open → index complete (line mode)	≤1 s	~35 s	~35×
Full-text search "東京" (6,204 hits — identical on both)	<1 s	~15–20 s	~15–20×
Show ±1 lines of context	instant	instant	equal
Jump from a hit to the source line	instant	instant	equal
Jump to middle (50%) / end (100%)	instant each	instant	equal

What it shows

The "readable the instant you open it" experience is essentially the same on both. UwView's core trick — instant page-mode open (never loading the whole file, drawing only what's on screen) — works in the browser too: content appears the moment you pick the file. UI actions like ±1 context and jumping from a result to the source line are instant in WASM as well — they're lightweight redraws, so the runtime barely matters.

The gap shows up in the heavy work: building the index and running full-text search. There, native wins big: ~35× on indexing and ~15–20× on search. WASM takes long enough to show a progress bar — about 35 s to index 100 M lines, 15–20 s to search "東京". Native finishes both in about a second.

Crucially, the hit counts matched exactly at 6,204 — so the speed differs, but the results are identical. The browser build isn't cutting corners on correctness. If that had drifted, the whole benchmark would be worthless, so confirming it mattered a lot.

Why the difference

Native UVF runs as native .NET with a memory-mapped file, using disk and CPU directly.
Browser WASM runs on WebAssembly (a step slower on CPU) and reads via asynchronous Blob.slice. Even with the same OS cache state, "scan-the-whole-thing" CPU work — indexing, full-text search — is where the gap opens up.

Conversely, "only what's visible" work like display and small redraws is plenty fast even in WASM.

Honest notes

The native run had this file warm in the OS cache (hence ≤1 s to index). But WASM's slowness is CPU-bound, so matching cache state wouldn't change the trend.
Timing is stopwatch-level (seconds).
Other terms (Nagoya, Osaka) behaved the same (~15–20 s each).

Which to use

The browser WASM build is about running UwView's features on the spot with zero install — handy for a quick peek at a huge file, or trying it on a shared machine.
For serious large-file work, use the free native UVF — indexing and search are an order of magnitude faster.
And for the fastest of all — instant re-open, archive storage — that's the paid UwView Pro.

"Same features work in the browser; real speed lives in the native build" — exactly as designed, and a satisfying result. UwView is free, so if you wrangle big logs, give it a try. The browser build needs no install: https://amru195704.github.io/UwView/

Full write-up & images (original): https://uvp.y42u.net/en/blog/uwview-uvf-vs-wasm-benchmark-en/
Source / roadmap: https://github.com/amru195704/UwView
Product ($129 one-time / $9 per month, cross-platform): https://uvp.y42u.net/en/pro-en/

I Opened 51GB / 890M Lines of Real Data — Then Calculated How Far It Could Theoretically Go (~9.2 Quintillion Lines)

y4u — Mon, 27 Jul 2026 01:10:04 +0000

When I released my large-file text viewer UwView on GitHub, I claimed it "handles up to roughly 200 million lines at high speed." But until then, my measurements were all on synthetic data — files containing nothing but sequential line numbers. So first I put it to the test on real data an order of magnitude bigger, and then I worked out how far it could go theoretically, straight from my own code's data types and structures.

For the test I chose an XML dump of the entire OpenStreetMap (OSM) Japan dataset. The result: a file of 51GB and roughly 890 million lines — more than four times the "200 million lines" the product advertises.

Repository: amru195704/UwView (PolyForm Internal Use License 1.0.0)

How I Built the Test Data — Turning OSM Japan into a 51GB XML File

OSM's Japan data is distributed by Geofabrik in binary .osm.pbf format (about 2.3GB), so I used osmium-tool to expand it into XML text (.osm).

# Download the pbf (2.3GB, binary)
curl -L -o japan-latest.osm.pbf \
  https://download.geofabrik.de/asia/japan-latest.osm.pbf

# Convert to XML (text) with osmium → 51GB, 890 million lines
osmium cat japan-latest.osm.pbf -o japan-latest.osm

The resulting file is UTF-8 text — an endless stream of <node> elements carrying latitude/longitude.

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.6" generator="osmium/1.19.1">
  <bounds minlat="20.08228" minlon="122.5607" maxlat="45.815403" maxlon="154.4709"/>
  <node id="31236558" version="5" timestamp="2020-06-27T07:40:04Z" lat="35.635073" lon="139.768101"/>
  ...

Counting with wc -l gives 892,239,125 lines — squarely in "no editor will ever open this" territory.

Measured Results (51GB, 892,239,125 lines, Apple Silicon Mac, external SSD)

Measured using the benchmark harness bundled with UwView (UwView.Bench).

Item	Measured value
File size	51,254,526,392 bytes (about 48 GiB)
Open + encoding detection	12 ms
Page-mode display (first 50 lines + 50 lines at the 50% position)	3 ms
Index build (one sequential read)	172.8 seconds (283 MB/s)
Total line count	892,239,125 (exact match with `wc -l`)
Checkpoint count (index)	3,485,310 entries ≒ 26.6 MB
Managed heap growth	33.3 MB
GetLine random × 1000	average 1.28 ms / p99 3.0 ms / max 5.7 ms
First-line fetch	`<?xml version='1.0' encoding='UTF-8'?>` (2.9 ms)
Jump to the last line (line 892,239,125)	`</osm>` in 0.006 ms
Encoding switch	3.4 ms (no index rebuild)
WorkingSet	12,083 MB (includes mmap'd pages; reclaimable by the OS)

Clearing the "200 Million Line Wall" Without Issues

What I most wanted to verify was whether things would hold up beyond the advertised 200 million lines. The short answer: no problems at all.

Accurate total line count: the 892,239,125 that UwView counted matched wc -l exactly, without a single line off.
Instant jump to the end: jumping to the last line (line 892,239,125, </osm>) took 0.006 ms. Once the index exists, jumping anywhere in the file is instantaneous.
Memory footprint stays flat: for a 51GB file, what's actually resident is roughly 26.6MB of index plus about 33MB of managed heap. The file itself is never loaded into memory.

UwView carries line numbers as a long (64-bit integer), but 890 million comfortably fits even within the int limit (about 2.14 billion). By design, line count is never going to be a bottleneck here.

Note that the "WorkingSet 12GB" figure looks large, but it's the cache of file pages touched via mmap — non-resident memory that the OS reclaims on demand under memory pressure. It is not memory the app itself has allocated.

The Difference from Synthetic Data — an Honest Look

Let's line up the earlier synthetic 200-million-line data against this run's real 890-million-line data.

Item	Synthetic 200M lines (5.1GB)	Real data 890M lines (51GB)
Index build speed	538 MB/s	283 MB/s
GetLine random (average)	0.005 ms	1.28 ms
Jump to last line	0.003 ms	0.006 ms
Index size	6.0 MB	26.6 MB

I'll be upfront that GetLine is slower than on synthetic data (0.005 ms → 1.28 ms). Three reasons:

Random reads on the external SSD are the limiting factor (an internal SSD would be faster).
Real XML has widely varying line lengths, so cache efficiency is worse than with synthetic data.
51GB doesn't fit entirely in memory (WorkingSet 12GB), so many reads end up hitting actual disk I/O.

Even so, it's still solidly in the single-digit-millisecond range, and scrolling and line-jumping feel plenty practical. The 283 MB/s index-build figure reflects a single sequential read of the full 51GB, and that number is entirely determined by storage speed.

Visible the Instant You Open It — the Strength of Page Mode

Another point worth emphasizing: you can start browsing without waiting for the index build (about 3 minutes). Opening plus encoding detection took 12 ms, and the first full screen rendered in 3 ms. Even for a 51GB file, the moment you open it — much like the instant less opens a huge file — the content is immediately visible in "byte-offset-based page mode," and once the index finishes building in the background, it quietly gets promoted to "line-number-based line mode."

There's no need to brace yourself for "opening a huge file" — the content is visible the instant you double-click. That's the experience UwView most wants to convey.

So How Far Can It Go, Theoretically?

With 890 million lines opening without trouble, I got curious: what's the theoretical upper limit on the number of lines? I worked through my own code's data types and structures to calculate the ceiling, step by step.

The short answer first: the type limit is about 9.2 quintillion lines

UwView tracks both line numbers and byte offsets as signed 64-bit integers (.NET's long) throughout. So the ceiling imposed by the data type itself is:

long.MaxValue = 9,223,372,036,854,775,807  (≈ 9.2×10^18 lines = about 9.2 quintillion lines)

That's already a number with no real-world relevance, but the story doesn't end there. In practice, several walls appear well before you'd ever reach it.

Wall #1: File size

Since byte offsets are also long, the largest file UwView can handle is roughly 8 EiB (exbibytes). And because the smallest possible line is just a single newline byte (\n), the "upper limit on line count" and the "upper limit on file size" both land in the same 8 EiB neighborhood. Of course, in the real world the file system's own maximum file size kicks in first (ext4 caps at 16TB per file; APFS and NTFS allow several EB, and so on).

Wall #2: The index structure

To keep memory usage low, UwView uses a sparse index that records a byte position only once every N lines (default N=256). These checkpoints are held in a List<long> — backed internally by an array — but .NET arrays are capped at about 2.14 billion elements (Int32.MaxValue).

So at the default setting, the index array hits its ceiling at:

2.14 billion × 256 ≈ 5.5×10^11 lines (about 550 billion lines)

This can be relaxed by increasing blockLines (N), but the index's memory footprint becomes the binding constraint before that. Index size is roughly "line count ÷ 256 × 8 bytes"; in this test, 890 million lines produced a 26.6MB index. Extrapolating out to 550 billion lines would require about 17GB of RAM for the index alone — and in practice, this is roughly where the real-world limit sits.

Wall #3: The real wall is "capacity"

To sum up, there are three layers:

Stage	Limit	Does it actually bind?
Limit imposed by the data type	~9.2×10^18 lines (about 9.2 quintillion lines)	Effectively unreachable
Effective limit imposed by the structure	~550 billion lines by default (extendable via settings)	Index RAM binds first
The real-world practical wall	Storage capacity	The realistic upper limit

The single biggest factor in the 890-million-line test was exactly this: file capacity binds before line count does. The 51GB file didn't fully fit in cache, and random reads dropped to millisecond-scale — but nothing broke. That's the natural consequence of a design that never keeps the whole file resident in memory (mmap), renders only the visible lines, and looks up line positions through a small sparse index.

So what's the actual real-world limit?

Reaching the type-imposed ceiling of 9.2×10^18 lines would require an 8 EiB-class file — far beyond anything a person could realistically provision. In practice, "the largest file you can actually get your hands on" is the real limit of the viewer.

That said, on a practical note: with as many as 890 million lines, building the index takes about three minutes and searches don't return results quickly. Something around 200 million lines is probably the comfortable sweet spot. The "up to 200 million lines" figure is only a rough guideline — in both the real-world test and the theoretical calculation, storage capacity becomes the limiting factor before line count does.

If anyone out there has an extremely large text file (hundreds of GB to TB scale) lying around, I'd genuinely love to hear where the limit actually lands when you open it in UwView.

Summary

Tested UwView on a real 51GB / 890-million-line dataset (OSM Japan as XML). It held up well beyond four times the advertised "200 million lines," with the total count matching wc -l exactly and a jump to the last line taking just 0.006 ms.
Resident memory is roughly 26.6MB of index plus 33MB of heap; the file itself is never resident. Browsing works in page mode from the instant it opens (12 ms / 3 ms) while the index builds in the background (about 3 minutes, 283 MB/s — storage-bound).
Theoretically, the type limit is about 9.2 quintillion lines (long) but effectively unreachable. Before that, the sparse index's array-element limit (about 550 billion lines by default) and index memory (about 17GB) bind first.
Past the index wall, what ultimately matters is the simple reality of storage capacity. The practical sweet spot is around 200 million lines.
The real-data conclusion — file capacity binds before line count — holds up exactly the same way in the theoretical calculation.

Sources

amru195704/UwView (GitHub) https://github.com/amru195704/UwView
OpenStreetMap Japan extract (Geofabrik) https://download.geofabrik.de/asia/japan.html
osmium-tool https://osmcode.org/osmium-tool/
Int64.MaxValue Property (.NET) https://learn.microsoft.com/dotnet/api/system.int64.maxvalue
Array class limits (.NET) https://learn.microsoft.com/dotnet/api/system.array

Premium Edition: UwView Pro (on sale now, Windows/macOS/Linux)

A commercial edition that lets you "instantly view and search huge files anytime, save the index so that from the second time on it opens instantly with line numbers, search up to about 9× faster, and store logs at about 1/9 the size while still opening them directly." One-time purchase $129 / $9 per month.
→ https://uvp.y42u.net/en/pro-en/
(With UwView / UwView Pro, you can view and search the entire file the moment you open it — even on the very first open. The index is built in the background, and line numbers appear once it's complete. UwView Pro saves the index and compressed cache, so from the second open onward it opens instantly with line numbers already in place. Other viewers show only the head until indexing finishes, whereas UwView lets you view and search the whole file instantly from the first open.)

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.

An honest comparison with klogg [v1.1.1]: I list every row I'm losing on, too

y4u — Sat, 25 Jul 2026 05:14:59 +0000

A while back I published a feature-comparison table between my large-file text viewer UwView and the industry-standard log viewer klogg. One rule: list every row I'm losing on, too. That table reflected the free version (UVF) at v1.0.0. Since then, v1.1 → v1.1.1 filled in a number of those "losing" rows, so here's the complete edition as of v1.1.1 — three columns (klogg, free UwView (UVF), and paid UwView Pro (UVP)), same items, status brought up to date. I still don't hide the rows where klogg wins.

Legend: ✅ = yes / 🔶 = partial or limited / ❌ = no (planned) / — = not applicable. Baseline: klogg 24.11.0, UVF v1.1.1, and an internal UVP build.

1. Performance & core (where UwView leads)

Feature	klogg	UVF 1.1.1	UVP 1.1.1
Instant open of huge files (browse the whole file before indexing finishes)	❌ Head only until indexing completes	✅ Instant page-mode display	✅ Same
Persistent index (reopening is instant)	❌ Re-indexes every time	❌ Rebuilds every time	✅ `.uwvz` (from a few ms)
Fast search via compressed cache	❌	❌	✅ (3–9× vs klogg, measured)
Archive workflow (delete original, keep ~1/9 size)	❌	❌	✅ Checksum-protected
Automatic Japanese encoding detection (Shift-JIS/EUC-JP)	❌ Manual	✅ Auto + manual switch	✅
Largest scale verified	~1B lines (claimed)	892M lines / 51 GB (measured)	Same
Browser (WASM) build	❌	✅ (bonus)	—
JA/EN UI switch	❌ English only	✅	✅

Opening a huge file and moving freely through the whole thing right away is clearly where UVF/UVP lead, and Pro is another order of magnitude ahead on reopening, search, and storage size (see the measured 3-size benchmark).

2. Search, filtering & color coding (big progress in v1.1 / v1.1.1)

Feature	klogg	UVF 1.1.1	UVP 1.1.1
Regex search	✅	✅ literal/regex	✅ + fast icase path
Results in a separate view + jump to text	✅ Bottom pane	✅ Popup (auto-shown)	✅ Per tab
Context lines around results (±N)	❌	✅ ±1	✅ ±1000
Save results to a separate file (with original line numbers)	❌	✅	✅
Match highlight + minimap distribution	🔶 Emphasis only	✅ Minimap + click-to-jump	✅
Multi-keyword color highlighter	✅	✅ v1.1 (32 colors, regex capture groups, 7 bundled presets, `.uwvhl` import/export, per tab)	✅ Same
Right-click instant coloring of a selected word	✅	✅ v1.1.1 (right-click → color, 3-tier word selection)	✅
Saved predefined filters / search history	✅	✅ v1.1 (50-entry history, ★ save)	✅
In-view incremental search (QuickFind, Ctrl+F)	✅	🔶 Mostly covered by next/previous	🔶 Same
Boolean search expressions (AND/OR)	🔶 via regex	❌	❌

The "log-analysis toolbox" — color highlighting, search history, quick coloring — where klogg had the edge in v1.0 is now almost entirely filled in. Bundled presets went from 5 (v1.1) to 7 after adding GeoJSON / KML in v1.1.1. QuickFind isn't implemented yet, but next/previous (< >) covers most of the need, so it's low priority.

3. Display & operation

Feature	klogg	UVF 1.1.1	UVP 1.1.1
Multi-file tabs	✅	✅ Drag & drop / multi-select	✅
Bookmarks (marks)	✅	✅ Toggle / prev-next / minimap	✅
Line selection (drag) → copy/save	🔶	✅ v1.1	✅
Rectangular (column) selection & copy	❌	❌	✅ v1.1 (Pro only)
Line-number display	✅	✅	✅
Scratchpad (base64/JSON/XML formatting workspace)	✅	❌ → planned	❌
Line-wrap display	✅	❌ → planned	❌

4. Monitoring (tail) & operations (klogg's remaining strengths)

Feature	klogg	UVF 1.1.1	UVP 1.1.1
Follow appended writes (`tail -f` equivalent)	✅ Follow mode	✅ Incremental index + auto-scroll	✅
Session restore (reopen the previous set of files)	✅	✅ v1.1.1 (near previous scroll position)	✅ v1.1.1
Recent files, favorites, start screen	✅ Recently used	✅ v1.1.1 (last 15, ★ favorites)	✅
Auto-updating search results while following	✅	❌ → planned (high priority)	❌
Per-file state restore (marks, encoding, Follow)	✅	❌ → planned (per-file)	🔶 Index persistent; marks etc. ❌
Log rotation / truncation handling	🔶	❌	❌

Around "resuming your work," v1.1.1's session restore, recent files, and favorites filled in most of the gap. What remains is auto-updating search tied to Follow and fine-grained per-file state restore.

5. Distribution & ecosystem (where klogg's overall strength counts)

Item	klogg	UVF 1.1.1	UVP 1.1.1
Price / license	Free, GPL (OSS)	Free, PolyForm Internal Use (source available)	Paid (commercial, on sale)
Supported OS	Win/Mac/Linux	Win/Mac/Linux + WASM	Win/Mac/Linux
Package distribution (Homebrew/Chocolatey/winget…)	✅ Extensive	🔶 GitHub Releases / Vector	🔶 Polar
OS shell integration / portable build	✅ (Windows)	❌ → planned	❌
Track record / user base	✅ 10+ years in the glogg lineage	🔶 Still building	🔶
Encoding coverage (Chinese, Korean, Cyrillic…)	✅ Broad (Qt base)	🔶 UTF-8/Shift-JIS/EUC-JP/UTF-16 → planned	🔶

Distribution, track record, and encoding breadth are where klogg is still clearly ahead. Those don't get filled in overnight, so I'm leaving them exactly as they are — honestly.

Rows filled in vs. still remaining (v1.0 → v1.1.1)

Filled in (klogg's edge → UVF now ✅ too): multi-keyword color highlighter, right-click instant coloring, search history / predefined filters, line selection → copy/save, session restore, recent files / favorites.
Still remaining (klogg still ahead): auto-updating search while following, per-file state restore, QuickFind (substitutable with next/previous), Boolean search, Scratchpad, line-wrap, package distribution / shell integration, track record / encoding breadth.

I don't hide the remaining items — they're all listed openly in the GitHub roadmap issue. I'll work through them top-down, not by copying klogg outright, but by designing each in whatever shape I find easiest to use myself.

Bottom line

Performance and the huge-file experience remain UVF/UVP's strength. Pro takes it another order of magnitude further (persistent index, compressed search, 1/9 storage).
The log-analysis toolbox gained color highlighting, quick coloring, search history, and restore features in v1.1/v1.1.1 — closing the gap with klogg considerably.
klogg's remaining advantages: Follow-linked search, per-file state restore, distribution, track record. All on the public roadmap.
If your work is routine log analysis and you value distribution and track record, klogg is still a solid choice. If you want to open and read huge files fast, auto-detect Japanese log encodings, and track things by color, give UwView a try — it's free.
And if a huge log is eating your disk and you want it compressed for storage while staying searchable at speed, 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).

Not a "klogg killer" — different tools for different jobs. I respect klogg and compare against it honestly.

Full write-up (original): https://uvp.y42u.net/en/blog/uwview-klogg-feature-comparison-v111-en/
UwView Pro ($129 one-time / $9 per month): https://uvp.y42u.net/en/pro-en/
Source / roadmap: https://github.com/amru195704/UwView
Browser demo (no install): https://amru195704.github.io/UwView/

I benchmarked my log viewer against klogg at 3/10/48 GB — the second open is the real win

y4u — Fri, 24 Jul 2026 13:33:45 +0000

If you work with logs, you know the wait: opening a multi-gigabyte file takes minutes before you can search. I built a large-file viewer, UwView, plus a paid UwView Pro (UVP), to cut the re-open wait to near zero. I ran a full 3 sizes × 3 storage tiers = 9-cell benchmark against klogg. Everything below is measured, with conditions.

Test setup (all of it)

Files (OpenStreetMap Japan, real data): 2.95 GB / 100M lines, 9.4 GB / 100M lines, 47.73 GB / 892,239,125 lines. (The largest is 51,254,526,392 bytes = 47.73 GiB; macOS shows it as 51.25 GB in SI. Same file.)
Storage: USB HDD (measured 0.10 GB/s) / USB SSD (0.41 GB/s) / internal SSD (3.29 GB/s) — a 33× raw-bandwidth spread.
Machine: MacBook Air, Apple M4 (10 cores), 32 GB RAM, macOS 26.3.1; klogg 24.11.0.
Search: average of 10 consecutive words (major Japanese city names), cold read included; the 48 GB row is a single run.
Validation: hit counts match klogg exactly in every cell (e.g., "Tokyo" in 10 GB = 1,211 hits).
Note: klogg timings are read off the GUI by eye, so they're approximate.

The honest part first (this is easy to get wrong): UwView lets you view the entire file the moment you open it — on the first open too, not just the second. (klogg shows only the head until indexing finishes; that's the real experience gap.) What does take time on the first open is building the index, and that time is on par with other tools — you read the file once, and physics is physics — but indexing runs in the background while you're already browsing and searching. On the second open the index is already saved, so there's no indexing at all: it's instant.

The "open" times below measure, for UVP, the time to build the index, and for klogg, the time until the text is actually viewable (klogg shows only the head until indexing finishes). Measuring UVP by time-to-view would be near-instant — on the order of 1,500× vs klogg — which makes no meaningful bar chart, so I deliberately handicap UVP with its index-build time instead. Values are summed over two opens of the same file (klogg rebuilds its index on every open ≈ ×2; UVP's second open is tens of milliseconds ≈ 0). Viewing itself is instant from UVP's first open.

The 9-cell table (open → search)

Size · Storage	klogg open (2×)	UVP open (2×)	klogg search	UVP search
3 GB · internal SSD	~4s	1.4s	~2s	0.40s
3 GB · USB SSD	~16s	8.3s	~2s	0.43s
3 GB · USB HDD	~94s	51.3s	~2s	0.72s
3 GB subtotal → ratio	~114s	61.0s → ~1.9×	~6s	1.55s → ~3.9×
10 GB · internal SSD	~7s	4.9s	~2s	1.20s
10 GB · USB SSD	~48s	27.8s	~3s	1.14s
10 GB · USB HDD	~220s	155.8s	~3s	2.41s
10 GB subtotal → ratio	~275s	188.5s → ~1.5×	~8s	4.75s → ~1.7×
48 GB · internal SSD	~30s	23.3s	~17.5s	5.1s
48 GB · USB SSD	~220s	138.5s	~128s	14.3s
48 GB · USB HDD	~1090s	637s	~585s	74.8s
48 GB subtotal → ratio	~1340s	798.8s → ~1.7×	~730s	94.2s → ~7.7×

Reading the table

Open (= indexing time; viewing is instant on either open): even summed over two opens, UVP is 1.5–1.9× faster — and every further open adds only to klogg's side (N opens → klogg ×N; UVP stays near its first). Look at first-open indexing alone and UVP is 10–30% slower (it's also building the compressed cache); by the second open it's already ahead in every cell.
Search: for RAM-fitting sizes (3–10 GB), ~1.7–3.9× — but klogg also returns in seconds there, so it's fine either way. Above RAM, at 48 GB, ~7.7×: klogg spends minutes per search (about 10 minutes on the USB HDD), which is a different experience. Regex is similar (10 GB, 10-word average: UVP 1.8–1.9 s).

Archive workflow (.uwvz)

You can delete the original and keep only a compressed cache (.uwvz, checksum-protected), then browse and search it directly. Disk footprint drops to 1/7–1/13: 3 GB→0.23 GB, 10 GB→1.29 GB, 48 GB→5.32 GB — and search still returns in seconds to ~75 s even on slow storage.

What it's actually doing

One idea: since you read the whole file on the first open anyway, build a compressed cache + index while you're at it, and never read the raw file in full again. It doesn't fight disk I/O physics — it reduces the number of bytes read. A 30-year-old large-viewer design, re-solved with a fast CPU, lots of RAM, and zstd.

On klogg (with respect)

klogg is an excellent, established tool with a strong log-analysis toolbox. UVP is tuned for the open-and-read experience of huge files and for compressed archival. My comparison article lists klogg's advantages honestly too. Different tools for different jobs — not a "klogg killer."

macOS first (Windows/Linux coming). Free build + a browser WASM demo to try instantly.

Full write-up & charts (original): https://uvp.y42u.net/blog/uwview-pro-benchmark-3sizes/
Product ($129 one-time / $9 per month): https://uvp.y42u.net/en/pro-en/
Source / roadmap: https://github.com/amru195704/UwView
Demo: https://amru195704.github.io/UwView/

DEV Community: y4u

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

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

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

Color Rules Are Built from Patterns and Background Colors

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

Search History and Predefined Filters Also Improved

Summary

Related Articles

Sources

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.

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

Round 1: klogg vs. current UwView — nearly identical

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

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

Overall comparison table — measured results

An honest note

Current status

Summary

Related articles

Sources

Shelve an Investigated Log at 1/9th the Size, Reopen It Tomorrow Right Where You Left Off

The Scenario — "I Want to Wrap Up Today's Investigation, but I Might Look at It Again Tomorrow"

Workflow 1: "Shelve It" Before Finishing the Investigation

Workflow 2: Pause Work While Leaving Tabs Open

When to Use Workflow 1 vs. Workflow 2

Why This Combination Works

Summary

Related Articles

I Expanded the Entire US OpenStreetMap to a Single 258 GB XML File — 4,509,830,821 Lines, and What Broke

Making the test file

The numbers

The line count broke int

You can read the file while the index is still building

Search time is bound by data scanned, not hits found

The sidecar is 11% of the original

Honest notes

Summary

Why We Split Search Results Into a Separate Window — Jump, Save, and Context Lines You Can Use \"While Looking\" With the Filter Popup

What Changed

1. Jump — go from the result list straight to the matching line in the document

2. Save — export the filtered results to a separate file

3. Context lines (±N) — see what the hit line alone doesn't tell you

Free vs. Pro

Why We Kept "Save" in the Free Version

Under the Hood (Briefly)

Summary

How much slower is the browser build, really? — UwView native (UVF) vs WASM, measured on the same file

Test conditions

Results

What it shows

Why the difference

Honest notes

Which to use

I Opened 51GB / 890M Lines of Real Data — Then Calculated How Far It Could Theoretically Go (~9.2 Quintillion Lines)

How I Built the Test Data — Turning OSM Japan into a 51GB XML File

Measured Results (51GB, 892,239,125 lines, Apple Silicon Mac, external SSD)

Clearing the "200 Million Line Wall" Without Issues

The Difference from Synthetic Data — an Honest Look

Visible the Instant You Open It — the Strength of Page Mode

So How Far Can It Go, Theoretically?

The short answer first: the type limit is about 9.2 quintillion lines

Wall #1: File size

Wall #2: The index structure

Wall #3: The real wall is "capacity"

So what's the actual real-world limit?

Summary

Related articles

Sources

The line count broke `int`