It's vaguely reminiscent of Vim's implementation, in the sense that I think, for large files, in it's default config, Vim keeps most of the text in it's swap file and pages it in as needed.

Vim's implementation also feels somewhat line-oriented in that if you load a large JSON file that has everything on 1 line and you try to edit that line, uh... it will be sluggish, but if you do, like %!jq '.' and format it, you can them move around the file a little easier.

Edit - What the heck while I'm at it:

Emacs - Historically used a Gap-Buffer which optimized more for locality of edits than loading large files. It doesn't suffer though as much from heap fragmentation though as the linked-list of strings type approach.

Monaco - The editor in VS Code recently went from a linked-list of strings to a PieceTree buffer. Which basically loads a the whole file into an immutable buffer and then uses the PieceTree to manage the edits.

Others - Lately people keep talking about Ropes, which is another tree type deal with extra-smarts specifically for text editing. I don't know of a game-changing editor like the others mentioned that uses it tho.

Ropes were introduced in this paper in the journal Software, Pracise and Experience: https://doi.org/10.1002/spe.4380251203 (best accessed from a university domain)

An example for an editor that uses them to manage large text files is Xi-Editor: https://github.com/xi-editor/xi-editor (edit: written in Rust).

Cool, I'm really interested in that paper, ty.

Wouldn't mind betting Sublime does a good job

It does. I loaded a 14GB file in it once.

xi-editor has some reasonably sophisticated handling for large files