# Performance

URL: https://tuios.dev/blog/topic/performance

> Profiles, benchmarks, memory and binary size.

## Posts

- [Most of the page was four fonts](https://tuios.dev/blog/most-of-the-page-was-four-fonts.md): A first visit to a sip page moved 11.7 MB. Most of it was four TTF files that nobody had compressed. WOFF2 and gzip took it to 4.4 MB, and dropping a fallback that no browser could reach took the binary from 30.1 MB to 24.6 MB.
- [A wait that made the pane 197 times slower](https://tuios.dev/blog/a-wait-that-made-the-pane-197-times-slower.md): An agent that waits for output with tuios wait-for made a flooding pane three times slower. I fixed how often the wait looked. On the libghostty-vt backend the same test still said 197 times, because each look read the history one cell at a time.
- [Making the binary smaller, and the idea that made it bigger](https://tuios.dev/blog/making-the-binary-smaller.md): Seven commits took the tuios release binary from 30.0 MB to 23.8 MB. A plan to leave screen saver data out of the binary made it 23.5 KB larger instead.
- [A full scrollback cost 232MB per pane, twice: once in the daemon and once in each client](https://tuios.dev/blog/48mb-per-pane-twice.md): A 112-byte cell made every scrollback line cost the full pane width. Packing cells, then storing lines as text, took a full ring from 232MB to 2.2MB.
- [Most of a scroll was spent on blank cells](https://tuios.dev/blog/most-of-a-scroll-was-blank-cells.md): A ten-character line scrolling off a 207-column screen walked the whole row twice. One int per row cut the short-line scroll from 1,120 ns to 240 ns, measured on a machine that would not sit still.
- [The renderer was drawing a backlog it had caused](https://tuios.dev/blog/drawing-the-backlog.md): A flooded tuios pane kept painting 1.2 s after its source exited. The client's own renderer caused the backlog, and pacing by queued bytes halved the tail.
- [A fifth of every frame went to changing nothing](https://tuios.dev/blog/a-fifth-of-every-frame-went-to-changing-nothing.md): A profile put 19.8% of the tuios client in lipgloss.Wrap, rewrapping pane text already the right width. Skipping it was easy. Proving the skip safe was the work.
- [The benchmark said 27x faster. It felt worse.](https://tuios.dev/blog/measuring-before-optimising.md): Fixing pane resize lag in TUIOS with Go benchmarks and pprof. Two of four theories were wrong, and the benchmark measured the wrong thing for three rounds.