Cache on windows runner takes a long time to load
Description: We run tests on runners with different OS using matrix. On ubuntu and macos the cache loads in an acceptable time (about 30 seconds), but on windows the cache loads for almost 12 minutes, which is very long. I didn't notice any windows related restrictions in the Readme.
Action version: actions/setup-go@v5
Platform:
- [ ] Ubuntu
- [ ] macOS
- [x] Windows
Runner type:
- [x] Hosted
- [ ] Self-hosted
Tools version: '1.22'
Repro steps:
Action: https://github.com/aquasecurity/trivy-aws/actions/runs/10383103541/job/28747388089?pr=210
Expected behavior: The cache loads quickly.
Actual behavior: The cache takes a long time to load.
Hello @nikpivkin ! Thank you for reporting this! We will investigate the issue and get back to you as soon as we have updates.
Hi @nikpivkin, Here are few reasons why windows takes more time than ubuntu and macos:
System Architecture: Windows has a different system architecture compared to Unix-based systems like Ubuntu and macOS, often resulting in higher overhead for tasks involving disk I/O operations. File System Differences: The NTFS file system used by Windows is generally slower for certain types of operations compared to ext4 (used by Ubuntu) and APFS (used by macOS). Disk I/O Handling: Windows tends to have more background processes and services that can interfere with disk I/O operations, leading to longer cache loading times.
After analysing the issue, we concur that the current duration for both installation and cache reloading isn't ideal. The cache reloading process should indeed be optimized for enhanced speed. We appreciate your feedback and will contemplate this as a potential feature request for future improvements rather than a bug.
Hello everyone,
We wanted to update you that a potential fix for the slow cache restore issue on Windows has been implemented in PR #515. This pull request aims to address the performance concerns reported in this issue.
Please note that this change introduces a breaking change. We encourage users to review the proposed modifications and share any feedback or concerns you may have. Your input is valuable to ensure the best possible outcome for all users. Thank you for your collaboration and continued support!
Hi @nikpivkin,
We have conducted extensive testing of the cache restoration process using actions/setup-go v5 and v6 across Windows runners, as well as with various runner configurations. Also, the initial slow cache loading observed on Windows runners was also related to underlying image IO performance issues, as discussed in @actions/runner-images/issues/8755. This discrepancy between the C drive and D drive on Windows runners contributed to slower workflow runtimes and impacted cache restoration speeds. We have found that the cache restoration functionality is now working robustly, and we are no longer experiencing delays or issues from our end.
For your reference, we have attached screenshots of recent workflow runs that demonstrate successful and timely cache restoration. We are also sharing workflow run link for your reference:
Given that the cache restoration issue appears to be resolved, we will not be proceeding with the implementation of PR #515. Thank you for your support and collaboration. Please let us know if you require any further information or if you encounter any related issues in your environment.
Hello @nikpivkin,
Just a gentle reminder! Could you please let us know if there are any updates from your side regarding this issue? Thank you!
Hello @nikpivkin,
Just checking in to see if there are any updates regarding this issue. Thank you!