An open's writes in a row to one place go in as one edit: a 10 MB body write is linear

Each body or data write copied and hashed the whole buffer, so a write the mount cut in 8 KB pieces was quadratic: 10 MB took 50 s and a 1 MB insert into 10 MB 11 s, holding the editor's turn. An open's appends to body, or inserts going on at data's address, are now held and put in as one splice (one copy, one undo step, one line-starts pass) before any other request, the close, or the editor's step once the writes pause 20 ms. fs.py-driven: 2 MB 2.19 -> 0.16 s, 10 MB 50.17 -> 0.78 s, 1 MB data into 10 MB 11.49 -> 0.26 s. A body-2m case (2 MB in 256 KB writes on one open) joins the perf gate: 84023 -> 15785 us; baselines re-recorded.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 5 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 5f3ef743..eab1b00d 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -768,7 +768,11 @@ shell writes it a line at a time), and the next open starts another. The
 pane has one history, so two opens writing at once take turns in it: each
 open's first write after the other's starts a step of its own; to
 make a loop's writes one step, write `1` (an undo point here), then `0`,
-the writes, then `1` again.
+the writes, then `1` again. An open's writes in a row to one place -- an
+append to `body`, inserts going on at `data`'s address -- are held and go
+in as one edit when anything else comes (another request, the close, or
+the editor's step once they pause 20 ms), so a 10 MB write is one copy, not
+one per 8 KB piece; any read sees them.
 
 One rule for what fails: a write fails whenever what it asked for fails,
 whether it came to a `ctl` (the root's, a pane's, a column's, a pane's