That is a 10 GB log. Keep it open all day and MrEditor holds none of it — it reads and draws only the lines you can see. Since v0.4 you can edit and save it in place, with atomic writes.
Signed with an Apple Developer ID and notarized by Apple — just double-click it. Universal (Apple Silicon & Intel).
Zero is not a rounding. The file is mapped, never copied: with all 10 GB open, vmmap reports 4.2 GB resident and 0 bytes dirty for it — pages the OS can drop at any moment, holding nothing of ours. The app itself has a 162 MB footprint (32 MB of that before you open anything); that is window buffers and the page tables for a 10 GB mapping, not your log. Measured 2026-07-12 on the shipping 1.0.2 build.
One take, real speed: a 10 GB log opens, and we scroll and search it while the line index is still being built in the background. When the index lands, the status bar stops guessing — 86,420,337 lines, exactly — and ⌘L jumps to the last one.
The index — counting all 86 million lines — takes about 10 seconds on this file. Watch the status bar: it shows an estimate (about 89,292,800) and settles on the exact count when the scan finishes. The view never blocks while that runs. Reading, scrolling and searching stay live throughout; the search in this clip finds 137,111 matches while the index is at 95%.
Out of 10 GB. The rest is streamed in the background to build a line index, and none of it is kept in memory. Loading the whole document first — the usual approach — falls over at this size. So MrEditor does not do that.
The file is memory-mapped. The OS pages in only what you actually touch — so opening is near-instant at any size.
Keep one byte offset every 2,000 lines. Any line is a quick scan away. The whole index is tiny.
A fixed-size view with a line-unit scroller — no 1.6-billion-point document view to blow past float precision.
tail -f, auto-scroll as it grows