How large a file can Linelark open?

There is no hard limit; the whole file is held in memory as UTF-16, so it costs roughly twice its size on disk. Anything over 24 MB asks before it opens.

Why are files with very long lines slow in some editors?

Because laying out one 100 KB line under word wrap is hundreds of rows. Linelark lays out only what is on screen and estimates the rest, so a long line costs something only when you look at it.

Is syntax highlighting kept on big files?

Yes. Files up to 256 KB are highlighted whole; larger ones are painted around what is visible, from cached line states, so a construct opened far above still colours correctly.

How were the numbers measured?

Release builds of 1.22.0 and 1.23.0, back to back on an Apple M5 Pro · 24 GB running macOS 27.0.1, driving the editor headlessly on a real 5.0 MB Claude Code transcript with word wrap on.

Large files

A 5.0 MB file with 126 KB lines,
open in 0.34 s.

Big files are rarely hard because they are big. They are hard because of their shape: a log, a minified bundle or an agent transcript puts a hundred kilobytes on one line, and an editor that touches the whole buffer when it needs a screenful pays for every one of them. Studio 1.23.0 stopped doing that, and this page is what changed, measured against 1.22.0 on the same file.

Download Studio 1.24.0 How it actually works

Studio 1.24.0 · macOS 14+9.0 MB download

The mechanism

Four whole-buffer costs, each found by measuring.

None of them was the file being large. Each was the editor doing something to all of it when a screenful would have done, and each now has a rule in the source so the next change cannot quietly bring it back.

Layout follows the viewport

Text is laid out non-contiguously: what is on screen, the caret and a scroll target are laid out for real, and everything else is estimated. Before, every keystroke and every redraw asked for the whole document to be laid out first — with word wrap on, a hundred-kilobyte line is hundreds of rows.

Typing does not rescan the file

The table of where each line starts is updated in place from the edit itself — the characters that changed and a shift of everything after — instead of being thrown away and rebuilt from the first byte on the next key.

Opening a second file leaves the first alone

Any preference change used to re-apply the font and the colours to every open buffer in every window, and a file joining Recent Files counts as one. Now only a change to the font, the tab width or the theme does: 982 ms became 58 ms with this file open.

Repainting colours is linear

Clearing the old syntax colours from a region used to go token by token, each step moving the rest of the list along. It is now one replacement, which is what took a 250 KB source file from most of a second per keystroke to about a tenth.

Colour only where you look

Files up to 256 KB are highlighted whole. Above that, the editor paints the visible lines and 200 more, and keeps the state each line starts in, so a block comment opened ten thousand lines earlier still colours correctly when you jump into the middle.

Unsaved edits are backed up as edits

Above 64 KB, the crash backup appends what you typed to a journal instead of copying the whole buffer after every burst — until the journal grows to half the file, when one fresh copy is cheaper.

Specifics

1.22.0 against 1.23.0, on the same file.

A real 5.0 MB Claude Code transcript: 1,422 lines, 10 of them over 60 KB, the longest 126 KB. Word wrap on, in a 1100 × 800 view.

Measured	Studio 1.22.0	Studio 1.23.0
Open: read, lay out, highlight and draw	9.9 s	0.34 s
Memory the open adds	+691 MB	+39 MB
One keystroke, repaint included	546 ms	41 ms
Opening another file while it is open	982 ms	58 ms
One keystroke in a 250 KB Swift file	845 ms	97 ms

Measured on 2 November 2026: Release builds of both versions, back to back on an Apple M5 Pro · 24 GB, macOS 27.0.1. The editor stack is driven headlessly, so these are the editor’s own share — a window server and the screen add a little to what a person sees. Memory is the change in physical footprint. Keystrokes are the average of twenty.

Before you rely on it

What is still true of a big file.

Estimating the text you have not looked at is what makes it fast, and the estimate has edges you can see.

The scroll bar is an estimateIn a large file its thumb is sized from text that has not been laid out yet, and it moves as you scroll and more of it is. On a 6 MB file of this shape the first estimate was out by nearly half.
With word wrap off, width grows as you scrollThe horizontal scroll range only knows the lines that have been on screen, so meeting a longer one further down widens it.
Small files are still repainted wholeUp to 256 KB the whole document is recoloured on every keystroke. It is linear now rather than quadratic, but it is the whole document: 97 ms per key on a 250 KB file in this measurement.
Coming back from a preview lays out the text above youReturning from a plugin preview to the place you were reading lays out everything before it, because a position built from estimates lands a dozen lines out. About half a second at the end of a 6 MB file, once.
The whole file is in memoryThere is no streaming or paging. Text is held as UTF-16, so a file costs roughly twice its size on disk, and anything over 24 MB asks before it opens.

Free, and staying free

Open it on
your own files.

Apple-notarized, macOS 14 and newer, Intel and Apple silicon.

Download Studio 1.24.0 9.0 MB · every version, with checksums