Skip to content

Measure the feed query at the size a follow list actually is - #78

Merged
sepehr-safari merged 1 commit into
mainfrom
bench-the-real-feed-shape
Aug 11, 2026
Merged

Measure the feed query at the size a follow list actually is#78
sepehr-safari merged 1 commit into
mainfrom
bench-the-real-feed-shape

Conversation

@sepehr-safari

Copy link
Copy Markdown
Contributor

The bench has always reported the feed shape over twenty authors, and at twenty authors it is free. A merged query opens one cursor per author and picks the newest across every live stream once per returned event, so its cost is set by how many people the reader follows, not by how many notes come back. Twenty is not a follow list, and measuring there made the hottest path in a client look like it costs nothing.

Two shapes on the same store, and one knob.

BENCH_AUTHORS sizes the store's author spread and the wide feed's follow set together, so every author that shape names has posted and no stream in the merge dies early. It defaults to 100, which is what the three existing shapes have always been measured against, so their numbers stay comparable release to release.

BENCH_FEED_LIMIT is the depth, because that is the number a reader raises by scrolling, and the merge pays the whole author set again for every extra note.

same feed by id answers the same question the other way: name the ids that arrived and read each directly. That is the comparison that matters for anything refreshing a feed it already holds.

On this machine, ReleaseFast, best of 50 and the lowest of repeated runs, 2049 authors over 210k events:

BENCH_FEED_LIMIT wide feed query entries examined
60 1.46 ms 60
300 3.46 ms 300
660 6.32 ms 660
1200 10.80 ms 1200

That is 0.97 ms of fixed cost plus 8.2 us per returned note, both proportional to the author count. The same eight notes named by id: 14 us.

Default run is unchanged:

warm feed query    : 500 notes in 267.5 us (best of 50; 20 authors, kind 1)
wide feed query    : 60 notes in 101.9 us (best of 50; 100 authors, kind 1, 60 entries examined)
same feed by id    : 8 notes in 11.8 us (best of 50; 8 ids named, 8 entries examined)
warm timeline query: 200 events in 95.4 us (best of 50; 1 author, any kind)
warm profile query : 1 event in 8.2 us (best of 50; 1 author, kind 0, 1 entries examined)

Bench only. No library code changed, all 163 tests pass.

The bench has always reported the feed shape over twenty authors, and at
twenty authors it is free. A merged query opens one cursor per author and
picks the newest across every live stream once per returned event, so its
cost is set by how many people the reader follows, not by how many notes
come back. Twenty is not a follow list, and measuring there made the
hottest path in a client look like it cost nothing.

Two shapes added on the same store, and one knob:

  BENCH_AUTHORS sizes the store's author spread and the wide feed's
  follow set together, so every author that shape names has posted and no
  stream in the merge dies early. It defaults to 100, which is what the
  three existing shapes have always been measured against, so their
  numbers stay comparable release to release.

  BENCH_FEED_LIMIT is the depth, because that is the number a reader
  raises by scrolling and the merge pays the whole author set again for
  every extra note.

  "same feed by id" answers the same question the other way: name the ids
  that arrived and read each directly. It is the comparison that matters
  for anything refreshing a feed it already holds.

On this machine, ReleaseFast, best of 50 and the lowest of repeated runs,
2049 authors over 210k events:

  limit   60 :  1.46 ms
  limit  300 :  3.46 ms
  limit  660 :  6.32 ms
  limit 1200 : 10.80 ms

which is 0.97 ms of fixed cost plus 8.2 us per returned note, both
proportional to the author count. The same eight notes named by id: 14 us.
@sepehr-safari
sepehr-safari merged commit b9ef115 into main Aug 11, 2026
2 checks passed
@sepehr-safari
sepehr-safari deleted the bench-the-real-feed-shape branch August 11, 2026 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant