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/
Top comments (0)