The naive look at this and say the performance must be poor because of all the copying involved. Wrong. The copy operation is incredibly quick and can be optimized in a variety of ways. Gap buffers also take advantage of usage patterns. You might jump all over the window before focusing and inserting text. The gap doesn’t move for display – only for insert (or delete).

On the other hand, inserting a character block at the head of a 500MB file then inserting another at the end is the worst case for the gap approach, especially if the gap’s size is exceeded. How often does that happen?

Contiguous memory blocks are prized in virtual memory environments because less paging is involved. Moreover, reads and writes are simplfied because the the file doesn’t have to be parsed and broken up into some other data structure. Rather, the file’s internal representation in the gap buffer is identical to disk and can be read into and written out optimally. Writes themselves can be done with a single system call (on *nix).

The gap buffer is the best algorithm for editing text in a general way. It uses the least memory and has the highest aggregate performance over a variety of use cases. Translating the gap buffer to a visual window is a bit trickier as line context must be constantly maintained.

Text editing algorithms (movement, display, etc.) are somewhat more straightforward if you already know where your lines break.

Ropes are significantly more complicated than a simple linked list of lines, particularly if you’re working in a language without GC. I can see memory fragmentation becoming a problem for ropes, too.

It’d be interesting to look at text editors released over the last decade or so to see what their internal model is. I doubt any of them use anything more sophisticated than linked lists, perhaps Emacs’s gap buffer. I’d be surprised if ropes were used.

Thanks for the comment.

Sure I could implement almost all of the basic datatypes if I wanted to (in fact I’ve partially implemented extensible vectors in elisp). I could also implement my own compiler, or database, or socket library or whatever. But why should I? A huge reason I use an imperfect, yet good enough language like Perl is the excellent libraries it provides. If I want a libraryless language, I know where to find Scheme.

I don’t agree that trees are much like hash tables, but that may be worth a whole post.

And yes, a linked list of lines would, in some ways, be better than an array. But is there any way it would be better than a rope?

One other obvious datatype is to use a linked list of lines; that makes copying characters around for inserts significantly less painful, as your N is only the number of characters in a line, rather than the size of your buffer.