Halve the file HugeFileDownloadTest transfers - #934
Merged
Conversation
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: 29.98s before, 5.47s and 5.50s 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
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.
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 actually needs — double the cost for the same coverage. It is now
Integer.MAX_VALUE + 1024L, still past the boundary, with the reasoning written on the constant so itdoes not get rounded back up.
The file itself is sparse, so this changes the transfer, not the disk footprint.
Measured on the class alone, deleting
target/hugefile.txtfirst so the file is recreated each time:Worth being straight about the scale: that is a real saving but a small share of a Verify run, which
has been taking 22–25 minutes on this repo for a while. The larger costs are
TckTestat 56.6s andthe Jetty/TLS classes —
HttpsWagonTest31.7s,HttpWagonPreemptiveTest29.6s,HttpsWagonPreemptiveTest30.1s,HttpWagonTest29.5s — and those are inherent to what they test.This change was created with AI assistance.