diff options
| author | Justin M. Keyes <justinkz@gmail.com> | 2026-08-17 07:55:47 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-08-17 07:55:47 -0400 |
| commit | 98053bfecf35901c041acee349e744ce9e951edf (patch) | |
| tree | 83c29b0027995b17c68204e44bea8a36e581634f /runtime/lua/vim | |
| parent | 5f07fc91c23196cac1ff39961d8f60f0dbd57749 (diff) | |
| download | rneovim-98053bfecf35901c041acee349e744ce9e951edf.tar.gz rneovim-98053bfecf35901c041acee349e744ce9e951edf.tar.bz2 rneovim-98053bfecf35901c041acee349e744ce9e951edf.zip | |
perf(input): drop buffheader_T #41353
Problem:
`buffheader_T` is a linked list (Vim's favorite data structure) with
complex bookkeeping, optimized for ancient hardware:
1. Memory topology: On old platforms (Amiga 512KB without MMU, MS-DOS
64KB segments), large contiguous allocations were hazardous (no VM).
2. Never-move appends: `add_buff()` fills spare space or links a new
block.
3. OOM "recovery": a failed block allocation only loses one append.
To avoid OOM, it prefers to allocate small, linked chunks, instead of
resizing one continguous slice. Each stuff/drain cycle costs
a malloc+free.
Solution:
Replace Vim's favorite data structure with Nvim's favorite data structure.
Nvim doesn't have granular handling of OOM (`xmalloc`), and hardware has
changed: caches favor contiguous memory, allocators handle
fragmentation. And these buffers are ~kb scale, so OOM is irrelevant on
any system that can run Nvim.
- Use a flat `StringBuilder` + `read`/`insert` offsets.
- Keeps capacity (does not shrink) until `free_buff`.
- "Steady state" allocates nothing: 1 fewer malloc+free per dot-repeat.
Diffstat (limited to 'runtime/lua/vim')
0 files changed, 0 insertions, 0 deletions