render: hash the glyph cache keys with foldhash #397

Merged

natsukium merged 1 commit from render/glyph-foldhash into main 2026-09-25 09:02:50 +09:00

Conversation 0 Commits 1 Files changed 3 +10 -5

natsukium commented 2026-09-25 01:27:10 +09:00

Owner

Copy link

The client's glyph cache hashed its per-cell keys with std's SipHash. On every frame the renderer walks each cell and looks it up in the primed set and the slots map. A DOOM-fire profile put that hashing at about 14% of the client main thread's samples.

Both containers now use foldhash::fast::RandomState. The keys come from PTY output: the grid's chars and OSC 66 sizing. The seed is therefore random per process, not the FixedState that felis-grid's intern tables use. Those tables tolerate a fixed seed because the style sweep bounds them. slots is not bounded: a glyph that rasterizes blank is cached without using atlas space, so it never triggers the reset that clears the map. With a fixed seed, a producer could precompute keys that share a bucket. The blank ones among them would pile up until something else fills the atlas and resets it. The random seed measured no slower than FixedState, so nothing is traded for it. The unbounded growth itself is #406.

Measured on an M4 Max: release build, default config, three alternating runs against main, 10 s of DOOM-fire each.

	main	this PR
client CPU time	7.86-8.04 s	7.29-7.44 s
frame rate	2,408-2,422 fps	2,409-2,443 fps
daemon CPU time	17.63-17.89 s	18.15-18.29 s

The daemon code is identical in both builds, yet its CPU time was about 2% higher in every run with this PR. The cause is unverified. One possibility is that a cheaper client answers more of the daemon's frames; the frame rate did not change.

cargo nextest run -p felis-render-wgpu: 267/267 pass. cargo clippy -p felis-render-wgpu --all-targets -D warnings: clean.

The client's glyph cache hashed its per-cell keys with std's SipHash. On every frame the renderer walks each cell and looks it up in the `primed` set and the `slots` map. A DOOM-fire profile put that hashing at about 14% of the client main thread's samples. Both containers now use `foldhash::fast::RandomState`. The keys come from PTY output: the grid's chars and OSC 66 sizing. The seed is therefore random per process, not the `FixedState` that felis-grid's intern tables use. Those tables tolerate a fixed seed because the style sweep bounds them. `slots` is not bounded: a glyph that rasterizes blank is cached without using atlas space, so it never triggers the reset that clears the map. With a fixed seed, a producer could precompute keys that share a bucket. The blank ones among them would pile up until something else fills the atlas and resets it. The random seed measured no slower than `FixedState`, so nothing is traded for it. The unbounded growth itself is #406. Measured on an M4 Max: release build, default config, three alternating runs against main, 10 s of DOOM-fire each. | | main | this PR | |---|---|---| | client CPU time | 7.86-8.04 s | 7.29-7.44 s | | frame rate | 2,408-2,422 fps | 2,409-2,443 fps | | daemon CPU time | 17.63-17.89 s | 18.15-18.29 s | The daemon code is identical in both builds, yet its CPU time was about 2% higher in every run with this PR. The cause is unverified. One possibility is that a cheaper client answers more of the daemon's frames; the frame rate did not change. `cargo nextest run -p felis-render-wgpu`: 267/267 pass. `cargo clippy -p felis-render-wgpu --all-targets -D warnings`: clean.

natsukium added 1 commit 2026-09-25 01:27:10 +09:00

render: hash the glyph cache keys with foldhash ... 9f9f9d5c9c

The client walks every cell of the grid on every frame, and each cell
costs two lookups keyed on small integer tuples: the `primed` set that
deduplicates the walk and the `slots` map that resolves the atlas
slot. Both used std's SipHash, which a samply profile of DOOM-fire put
at about 14% of the client main thread's samples. The keys come from
the font stack and the grid, not from anything a peer can choose to
collide, so the DoS resistance SipHash buys is not needed here; felis
grid's intern tables already use foldhash for the same reason.

Measured on an M4 Max (release, default config, three alternating runs
against main, 10 s of DOOM-fire each):
- client CPU time: 7.89-8.07 -> 6.70-6.87 s
- frame rate: 2,403-2,419 -> 2,395-2,422 fps (unchanged)
- daemon CPU time: unchanged

Assisted-by: Claude Code:Opus 5.5

natsukium referenced this pull request 2026-09-25 01:34:54 +09:00

bench: the felis CPU split in the resource-use tables disagrees with #397's measurement #398

natsukium referenced this pull request 2026-09-25 01:34:54 +09:00

daemon: CPU time under sustained output is 1.3-1.9x the leading peer's #399

natsukium referenced this pull request 2026-09-25 01:35:05 +09:00

bench: follow up the 9d1d842f cross-terminal run #405

natsukium force-pushed render/glyph-foldhash from 9f9f9d5c9c to c9762f90be 2026-09-25 01:36:30 +09:00 Compare

natsukium force-pushed render/glyph-foldhash from c9762f90be to 1f9eb8cf79 2026-09-25 01:36:46 +09:00 Compare

natsukium force-pushed render/glyph-foldhash from 1f9eb8cf79 to 63ccb930c7 2026-09-25 02:07:13 +09:00 Compare

natsukium referenced this pull request 2026-09-25 02:07:44 +09:00

render: blank glyphs grow the glyph slot map and shape cache without bound #406

natsukium force-pushed render/glyph-foldhash from 63ccb930c7 to 450344a59f 2026-09-25 02:08:41 +09:00 Compare

natsukium referenced this pull request 2026-09-25 02:16:11 +09:00

bench: the felis CPU split in the resource-use tables disagrees with #397's measurement #398

natsukium referenced this pull request 2026-09-25 02:17:30 +09:00

bench: the felis CPU split in the resource-use tables disagrees with #397's measurement #398

natsukium referenced this pull request 2026-09-25 02:18:27 +09:00

client: a window that cannot present keeps pulling frames unpaced #407

natsukium referenced this pull request 2026-09-25 02:18:36 +09:00

bench: the felis CPU split in the resource-use tables disagrees with #397's measurement #398

natsukium force-pushed render/glyph-foldhash from 450344a59f to 990c95947f 2026-09-25 09:01:41 +09:00 Compare

natsukium merged commit a964ff0de9 into main 2026-09-25 09:02:50 +09:00

natsukium deleted branch render/glyph-foldhash 2026-09-25 09:02:50 +09:00

natsukium referenced this pull request from a commit 2026-09-25 09:02:50 +09:00

render: hash the glyph cache keys with foldhash (#397)

Commenting is not possible because the repository is archived.

Reviewers

No reviewers

Labels

Clear labels   

priority/P0

Must be resolved before the v0.1.0 tag

  

priority/P1

Must be settled before the first public contract freezes

  

priority/P2

Explicitly deferred until after v0.1.0

  

release/v0.1.0

Work tracked for the first tagged release

  

status/blocked

Cannot start now: waits on an upstream release, another issue, or a recorded revisit trigger

  

status/planned

Triaged with a source-grounded plan and a passed pi review; ready to implement

  

type/bug

Shipped behavior that contradicts the docs or the code's own intent; needs a product code change

  

type/design

An open scope or trade-off question; needs a recorded decision in the owning explanation doc before code

  

type/test-gap

Documented or reviewed behavior that no test pins; usually split from a review finding, needs no product code change

  

type/tracker

Parent issue that tracks child work

No labels

priority/P0

priority/P1

priority/P2

release/v0.1.0

status/blocked

status/planned

type/bug

type/design

type/test-gap

type/tracker

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

natsukium/felis!397

No description provided.