Change --concurrency-factor from int multiplier to float64 CPU ratio#74
Change --concurrency-factor from int multiplier to float64 CPU ratio#74mason-sharp merged 1 commit intomainfrom
Conversation
On large machines (e.g. 96 CPUs), the old integer multiplier on runtime.NumCPU() created excessive workers with no way to reduce below 1× CPU count. Changing to a float64 ratio (default 0.5) lets users dial concurrency down on large hosts (e.g. 0.5 on 96 CPUs = 48 workers). - CLI flag: IntFlag → Float64Flag, default 0.5, valid range (0.0, 4.0] - All struct fields and config: int → float64 - Computation: math.Round(NumCPU * factor) with floor of 1 - API handler, jobs config, HTML reporter updated accordingly - Documentation and OpenAPI spec updated Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe change converts the Changes
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Tip Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
docs/commands/diff/table-diff.md (1)
47-48:⚠️ Potential issue | 🟡 MinorSample output shows 16 workers on 16 CPUs, which implies
--concurrency-factor 1.0rather than the new default0.5.With the default of
0.5, a 16-CPU machine would produce 8 workers. The sample output could confuse users who expect the default to match what's shown. Consider updating toUsing 16 CPUs, max concurrent workers = 8(or adding an explicit--concurrency-factor 1.0to the example command) so the output aligns with the documented default.
🤖 Fix all issues with AI agents
In `@docs/commands/diff/repset-diff.md`:
- Around line 24-27: The markdown table rows for flags `--block-size`,
`--concurrency-factor`, `--compare-unit-size`, and `--output` currently place
the default values inside the Description column; split each row into four cells
so the fourth cell contains the Default (e.g., move "Default `100000`", "Default
`0.5`", "Default `10000`", "Default `json`" into the fourth column), ensuring
the pipe separators produce four columns per row and match the table header
format used in `schema-diff.md`.
In `@docs/commands/diff/schema-diff.md`:
- Around line 24-28: Table rows for the flags (--skip-file, --block-size,
--concurrency-factor, --compare-unit-size, --output) are missing the dedicated
"Default" column cell; move the default values out of the Description cell and
into a separate fourth cell so each row has four pipe-separated cells matching
the header (e.g., add a cell containing the default like `Default: 100000` or
just `100000` for `--block-size`). Update the rows for `--skip-file`,
`--block-size`, `--concurrency-factor`, `--compare-unit-size`, and `--output` to
include the fourth cell and ensure spacing/pipe alignment matches the table
format used elsewhere.
🧹 Nitpick comments (1)
docs/openapi.yaml (1)
459-461: Consider addingminimum/maximumconstraints to enforce the documented range.The description documents a valid range of (0.0–4.0], but the schema has no
minimum/maximumorexclusiveMinimumconstraints. Without these, API consumers won't get schema-level validation errors for out-of-range values (e.g.,-1or10.0). The same applies to theSchemaDiffRequest(Line 564) andRepsetDiffRequest(Line 598) schemas.Suggested fix for TableDiffRequest (apply similarly to the other two)
concurrency_factor: type: number + exclusiveMinimum: 0 + maximum: 4 description: CPU ratio for concurrency (0.0–4.0). Defaults to table_diff.concurrency_factor or 0.5.
On large machines (e.g. 96 CPUs), the old integer multiplier on runtime.NumCPU() created excessive workers with no way to reduce below 1× CPU count. Changing to a float64 ratio (default 0.5) lets users dial concurrency down on large hosts (e.g. 0.5 on 96 CPUs = 48 workers).