Halve the file HugeFileDownloadTest transfers - #935
Merged
Conversation
Backport of the same change on master; this branch's copy was identical to master's before it. The point of the test is a byte count that overflows an int, so the size only has to exceed Integer.MAX_VALUE. It was twice that, which doubled the transfer without widening what the test checks. Dedicated runs of the class on this branch: 12.70s before, 5.08s after.
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.
Backport of #934. This branch's copy was identical to master's before that change, so it applies
verbatim.
HugeFileDownloadTestexists to catch a byte count held in anint, which overflows aboveInteger.MAX_VALUE. The constant was set to twice that, so every run transferred ~4 GiB rather thanthe ~2 GiB the check needs. It is now
Integer.MAX_VALUE + 1024L, still past the boundary, with thereasoning written on the constant. The file is sparse, so this changes transfer time, not disk use.
Measured on this branch, on the class alone, deleting
target/hugefile.txtfirst so it is recreated:The before figure is lower than the 29.98s measured on master for the same starting code — same
machine, so treat these as one machine's numbers rather than a benchmark; the direction and the
reason for it are what matter.
This change was created with AI assistance.