docs(readme): round the 64 KiB batch bound out to the widest published row - #201
Merged
Merged
Conversation
…d row The bound reads the table's ratio column, which reports each backend's best-throughput cell, as if it were that backend's maximum ratio. It is not. RabbitMQ at 64 KiB with one consumer drains 27 818 msg/s batched against 18 997 msg/s parallel - 1.464x, both rows `framework`, both published - so a "at most 1.35x" bound has a counterexample in the document it cites. Rounded outward across every published 64 KiB cell the bound is 1.5x. The table itself is unchanged: all eighteen cells reproduce from `benches/results/bench-results.json`, and RabbitMQ's 1.3x is the ratio at the 4c cell the table names, which is correct. Also names SQS's comparator. SQS has no `consume_parallel` rows - it is `ConsumerSupervisor` there - so "the ratio to the plain parallel consumer" described a flow that backend does not record.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
shove-docs | d04a49f | Commit Preview URL Branch Preview URL |
Sep 11 2026, 12:08 PM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One published row falsifies the
1.35xbound added in #199.Depends-on: none — corrects a claim already on
main; the results document it cites is unchanged.The counterexample
RabbitMQ, 64 KiB, one consumer:
consume_batch27 818 msg/s overconsume_parallel18 997 msg/s = 1.464x. Both rows areframework, both aremethod: drain, both publish.The bound was read off the table's ratio column, which reports the ratio at each backend's best-throughput cell — for RabbitMQ that is 4c at 1.341. That column is correct and unchanged; it just isn't a maximum. Per-cell 64 KiB ratios, published cells only:
Dashes are cells where one side of the pair is
setup_boundor absent, so no ratio publishes. Rounded outward the true bound is 1.5x.Second change: SQS's comparator
The paragraph says the ratio is "to the plain parallel consumer at that same cell". SQS has no
consume_parallelrows — its flows areconsume_batch,consume_fifo,dlq_drain,publish_*andsupervisor, becauseHasCoordinatedGroupsexcludes it andConsumerSupervisoris what it uses instead. The SQS figures in the table are batch oversupervisor, which is the right comparator; the prose named a flow that backend does not record. One clause added.What I checked
All eighteen table cells reproduce from
benches/results/bench-results.jsononmain— best published (framework,method: drain)consume_batchcell per backend and payload, its consumer count, and the ratio at that cell. Every one matches, including SQS. No number in the table changes here.Prose only; no code, no results document, no charts.