Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup-node is abnormally slow on Windows (?) #975

Open
2 of 4 tasks
charlespwd opened this issue Feb 27, 2024 · 9 comments
Open
2 of 4 tasks

setup-node is abnormally slow on Windows (?) #975

charlespwd opened this issue Feb 27, 2024 · 9 comments
Labels
feature request New feature or request to improve the current logic

Comments

@charlespwd
Copy link

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

image
image

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

@charlespwd charlespwd added bug Something isn't working needs triage labels Feb 27, 2024
@HarithaVattikuti
Copy link
Contributor

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
Copy link

Titozzz commented Mar 4, 2024

@gowridurgad gowridurgad self-assigned this Apr 1, 2024
@gowridurgad
Copy link

gowridurgad commented Apr 8, 2024

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
Screenshot 2024-04-08 at 2 07 08 PM
Screenshot 2024-04-08 at 2 31 01 PM
Screenshot 2024-04-08 at 2 31 55 PM

@charlespwd
Copy link
Author

charlespwd commented Apr 10, 2024

👋 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:

Image

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

Image

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

@gowridurgad
Copy link

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
Copy link

Hello @charlespwd
Just a gentle reminder!

@charlespwd
Copy link
Author

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
Copy link

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.

@HarithaVattikuti HarithaVattikuti added feature request New feature or request to improve the current logic and removed bug Something isn't working labels May 15, 2024
@gowridurgad gowridurgad removed their assignment May 15, 2024
@charlespwd
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

4 participants