setup-node is abnormally slow on Windows (?)

[charlespwd]

Description:
actions/setup-node@v4 on Windows takes ~4min
actions/setup-node@v4 on Ubuntu takes ~5s

Action version:
4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted

Tools version:
yarn

Repro steps:
A description with steps to reproduce the issue. If you have a public example or repo to share, please provide the link.
https://github.com/Shopify/theme-tools/actions/runs/8066227793/job/22033787811

Expected behavior:
Windows cache-get doesn't take north of 2minutes when Ubuntu completes in 10s

Actual behavior:
Windows setup-node is significantly slower on Windows than Ubuntu

[HarithaVattikuti]

Hello @charlespwd
Thank you for creating this issue. We will investigate it and get back to you as soon as we have some feedback.

[Titozzz]

I can confirm it reproduces here too: https://github.com/react-native-webview/react-native-webview/actions/runs/8134361620/job/22227194192

[gowridurgad]

Hi @charlespwd If there is no cache actions/setup-node@v4 on Windows takes ~16s .when we re-run the job it takes some time to build the cache so setup-node takes more then 2 min to run. when we run the job again this time it takes less than 2 min because the cache was already there. The Subsequent runs are faster because the dependencies are loaded from the cache instead of being downloaded and installed again. Here is the screenshots for reference. And also Please make sure that your project is upgraded to node 20 because we have a cache fix for node 20 upgrade as part of this PR

[charlespwd]

👋 It's much better indeed, but I feel like caching should be faster than without a cache. And right now the runtimes are almost equivalent. Anecdotal, but it seems like the action gets caught up by the tar.exe process. I seem to reach 100% rather quickly, and then have to wait for the de-archiving process.

Here's a test I have made with cache: '' on our repo:

And here's a test with cache: 'yarn' (cache is warm)

The experience is very different on a ubuntu-latest instance.

[gowridurgad]

Hello @charlespwd , We have done more investigation with regards to cache and it is the expected behavior from cache and here are few reasons why windows takes more time than ubuntu:

1. Windows and Ubuntu use different file systems (NTFS and EXT4 respectively), which have different performance characteristics. For example, NTFS might be slower when dealing with a large number of small files, which is often the case when caching dependencies.
2. There have been reports of slower network and disk IO on Windows GitHub Action agents, which could affect the time it takes to restore a cache.
3. Windows has different system processes and services running in the background compared to Ubuntu, which could affect the performance.

[gowridurgad]

Hello @charlespwd
Just a gentle reminder!

[charlespwd]

It feels weird to me that it should be OK that installing and unzipping a cache entry takes (roughly) same amount of time. What's the point of caching in this case 😅? The whole purpose of using this is to save time. Are we really happy with that outcome?

[gowridurgad]

Hi @charlespwd, Apologies for the late response. Upon further investigation, 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.

[charlespwd]

No worries. I understand what it's like to juggle a lot of priorities. Thank you 🙏