Builder: the first build after the next release spends ~8 minutes opening every game file (damaged-texture check, one file at a time) #2754
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#2754
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why it matters: #2391 (merged Nov 11, in no release yet) bumps the check version in
.hookshot_romfs_checked, so every game folder already checked runsnup.damaged_game_filesagain on its first build with the next release. The extraction's list of damaged files (#1885) is deleted after the first check, so that build opens every romfs.zsfile (102,185), one at a time. On Windows each first open of a file took about 4-5 ms here, which I attribute to Windows Defender scanning it (not confirmed with the scanner off): the build shows only its "checked N of 102,185 files" progress for about 8 minutes.Builder version
mainatba005ca4, built from source withnx2/make_game.py --nup(the Builder's own steps).How you built
A fresh unpack into a new game folder; then
.hookshot_romfs_checkedremoved, as the check-version bump does; then the same build again. The full check then runs over files not opened since they were written.Game files given to it
A complete base-game
.nup(about 23.8 GB).The error
No error: a long wait. From the second build's log:
Two separate fresh folders: 486 s and 492 s, out of builds of 490 s and 509 s. The same check run again over the same files takes 5.0-5.9 s.
Visual Studio or Build Tools version, and Windows SDK version
None: the C compiler was the Builder's own llvm-mingw (the check runs before any compile).
Operating system and free space on the output drive
Windows 11 Home 10.0.26300, Windows Defender on; i9-13900K, 64 GB, NVMe; 115 GB free.
Score
As in docs/workflow.md: S3 (a one-time wait; the build finishes) x reach 0.57 (Windows; every installed game on its first update after #2391) x confidence 1.0 (reproduced, log above) = 0.57.
Claim
I'm taking this, on an RTX 4090, i9-13900K and Windows 11. The plan is to open the files from a thread pool, keeping the results and the progress in the listed order. Measured on fresh unpacks, two interleaved pairs: 486 and 492 s before, 27 and 28 s after, with the same files found. The PR follows a game run on that build.
Tracking: #2505
Before you send it
main, newer than the newest release)PR: #2769 (the game run on that build is in its description and in docs/tested-configurations.md).