fix(cli): Defer zero-duration chunk adjustment#282
Open
leongdl wants to merge 1 commit into
Open
Conversation
Signed-off-by: David Leong <116610336+leongdl@users.noreply.github.com>
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
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.
What was the problem/requirement? (What/Why)
Adaptive chunk sizing divides the cumulative task duration by the number of completed items. A task that completes below the clock's measurable resolution can produce a cumulative duration of
0.0. With a positive target runtime, the next calculation produces infinity, and converting that value tousizesaturates tousize::MAX. The iterator then attempts to place the remaining parameter range into one enormous chunk.Call stack
What was the solution? (How)
Extract the numeric calculation into
calculate_adaptive_chunk_sizeand defer adjustment when the cumulative duration is non-positive or non-finite. The iterator retains its current chunk size until a measurable timing sample is available, avoiding an arbitrary epsilon and preventingusize::MAXfrom being installed.The existing conservative blend for the first ten completed items is unchanged for measurable durations. Focused unit tests cover both zero-duration deferral and normal early-sample blending.
What is the impact of this change?
Sub-clock-resolution tasks no longer cause adaptive execution to collapse the remaining range into a single giant chunk. Normal adaptive chunk sizing is unchanged. There is no public API change.
How was this change tested?
cargo test -p openjd-cli run::execution::tests— 2 passedcargo test -p openjd-cli --test cli_tests— 152 passedcargo test --workspace— passedcargo clippy --all-features --all-targets --workspace -- -D warnings— passedcargo fmt --all -- --check— passedWas this change documented?
Yes.
specs/cli/run.mdnow documents that adaptive sizing waits for a measurable duration before changing the chunk size.Is this a breaking change?
No.
Does this change impact security?
No.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.