-
Notifications
You must be signed in to change notification settings - Fork 128
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
[Bug]: bad startup performance #2090
Comments
experienced this too ever since I migrated from cli 2.x to 3.x, there's something throttling theme commands vs how it was before |
I'd recommend running with the |
@amcaplan Thanks for looking into this! I provided the first lines of the verbose output. There is just plain nothing happening for the first 10 seconds, even before the first line of verbose output. My first guess would go in the direction of node startup time - any way to improve that? |
Just leaving this here: https://blog.logrocket.com/snapshot-flags-node-js-v18-8/ If node really is the problem here, there might be some ways to improve startup time. Any ideas on how to check what actually is the problem here? |
You can also try again setting You can also try running |
Thanks for the pointers! Running `node -e "console.log('hello')"`` returns hello instantly. |
I ran until it finally loads the shopify files, runs, and returns instantly. Adding most of the files node accesses to the allowlist of defender improved performance by ~30%, but it was not the improvement I hoped for. I would love to try out snapshotting for node, like in https://blog.logrocket.com/snapshot-flags-node-js-v18-8/ Maybe we could create the snapshot on first run and store it. |
@Christoph-AK thanks for the context! My read of this is that most of the time is taken by loading dependency packages, which is quite slow on Windows compared with Linux or Mac systems, due to a mixture of NTFS and subsystem design issues. Simply put, Windows is not built to run Node, where the common practice is to load many small files on startup. Unfortunately, this isn't going to be as simple as a snapshot, because:
It's possible we could use pkg to come up with some kind of solution... but at any rate, it's going to be a heavy lift. If the speed is too slow to deal with, it might be best to try other terminals or set up WSL on your machine, which should be much faster at loading dependencies. Wish I had a better suggestion, but I don't at the moment. Will share your findings with the team, though. |
Can you elaborate on what you've experienced? What level of slowdown? |
Hey @amcaplan ! It's a similar thing to what @Christoph-AK is experiencing, I also use Windows, 11 in my case. In CLI 2.x which was running on ruby gems, right? commands and data fetching was fast, so running in CLI 3.x now that is running on node, commands like I guess it's not unusable! but if we can find a solution would be nice. Below is some samples i took, let me know if you would like me to do other types of tests! Video Demo with Recording.2023-06-08.092343.mp4
|
From here it looks like Microsoft is pretty open about being very slow for Node applications. So unless we'd choose to rewrite the CLI in another language (unlikely at the moment), this isn't something we can fix easily. However, as mentioned above, WSL is a very good option. Additionally, Windows Insider builds have a Dev Drive feature where you can move your npm cache for significantly better performance. @muchisx it looks like some of what you're experiencing is slowness on refreshing your login. Recall that on CLI2 you'd run a command, get told to log in again, then log in, then run the command and succeed? On CLI3 we take care of this within the command, including refreshing your authentication. We could probably give better UI feedback about what's happening (e.g. a taskbar saying we're refreshing your authentication) but it's impossible to circumvent the need to be certain we have valid authentication before proceeding. That's also why the second run of the command is significantly faster. |
This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. P.S. You can learn more about why we stale issues here. |
Not sure if I'm super happy with this being closed. I'm really looking forward to the mitigations in dev drives and will report back with observaitons once I get my hands on that feature, but this is still a really big problem for us, and we cant spare the 6GB and management overhead to run wsl on our dev machines at the time. I would love to see some kind of improvement in windows startup time, but I am unsure if and how this could be achieved in the current system. Kinde makes this an ideal candidate to rewrite in rust 🦀, doesn't it? 😁 |
This issue seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action. P.S. You can learn more about why we stale issues here. |
This all sound fairly lame. I think it is obvious that V3 CLI runs very slowly and to say it is a "Windows" thing is not really a valid response. I run node under Windows and Linux as well as in WSL and all other packages do not have extreme differences in performance. Has any analysis been done as to why exactly it runs slow, which dependencies, alternatives etc? Just letting |
Please confirm that you have:
In which of these areas are you experiencing a problem?
Theme
Expected behavior
Running
shopify theme dev --store shop.myshopify.com
starts executing immediately.Actual behavior
Running any command (version as well) takes 5+ seconds to run. For a modern application we are running hundreds of times a day thats not really great.
Verbose output
Reproduction steps
Operating System
Windows 11 22H2 (22621.1702)
Shopify CLI version (check your project's
package.json
if you're not sure)3.46.2
Shell
powershell with starship
Node version (run
node -v
if you're not sure)v16.14.2
What language and version are you using in your application?
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x64-mingw-ucrt], pnpm 8.6.0
The text was updated successfully, but these errors were encountered: