nodejs and yarn are 4x slower on windows than ubuntu

[asklar]

npm and yarn are the bread and butter of package management for the nodejs ecosystem, of which react-native is a part of.
Yet, these tools are very slow and finnicky on Windows. There are many stackoverflow posts about people asking why yarn is so slow.
We feel this pain ourselves too (RNW team) and we hear it from people coming form mac OS or Android and wanting to add Windows versions of their RN apps.

I recently added a CI loop in github actions, that does the exact same thing for a popular 3rd party npm package I contributed to (envinfo): install yarn dependencies, build the typescript, run the package.

What I saw was that Windows took 4 times as long as ubuntu to do end-to-end install of the package and running it once.
I imagine part of it is that the yarn/nodejs implementation is suboptimal on windows, but it seems that even github actions is spending a lot more time doing things on Windows that aren’t “run the user’s code” than on Ubuntu.

What's worse is that the ubuntu virtual hardware seems a lot less powerful than Windows', so the actual measure is probably a lot worse than 4x.

Here are my measurements:

	ubuntu	Windows
Set up job	2s	1s
Run actions/checkout@v2	1s	26s
Use Node.js 10.x	1s	15s
Run yarn	43s	2m 19s
Run node --unhandled-rejections=strict src/cli.js	18s	1m 0s
Post Run actions/checkout@v2	0s	17s
Complete job	0s	0s
Total	65	258
		3.97x
Machine class	Standard_DS2_v2	Standard_D4_v2
vCPU	2	8
Memory	7	28
Temp storage	14	400
Max temp storage throughput: IOPS/Read MBps/Write MBps	8000/64 (86) cached 6400/96 uncached	24000/375/187
Max data disks	8	32
Throughput: IOPS		32x500
Max NICs/Expected network bandwidth (Mbps)	2/1500	8/1/6000

[Qix-]

I'll be the first person to point out the deficiencies of the Windows platform to anyone who asks, but I really don't see how this is Microsoft's problem.

Further, before I fully respond, I'm a bit confused - your title states "nodejs and yarn" but your post states "npm and yarn". Are you referring solely to the package managers, or are you claming Node.js as a whole is 4x slower?

In either case, there's nothing stopping these applications from profiling and fixing bottlenecks on Windows. It is very clear that, at the foundational level, properly written software can perform just as well on Windows as other platforms. Having dealt with both the npm and yarn source code, both are in very large part bloated and unoptimized (npm especially).

---

Here's just some stats from both projects.

$ cd /src/npm/cli && cloc bin lib
     204 text files.
     204 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 1.82  T=0.55 s (372.5 files/s, 34479.9 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                     196           1984            886          15794
Bourne Shell                     4             14              8            117
DOS Batch                        3              8              0             36
Markdown                         1              9              0             28
-------------------------------------------------------------------------------
SUM:                           204           2015            894          15975
-------------------------------------------------------------------------------

$ cd /src/yarnpkg/yarn && cloc src bin
     167 text files.
     167 unique files.
       2 files ignored.

github.com/AlDanial/cloc v 1.82  T=0.50 s (330.3 files/s, 53159.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
JavaScript                     161           4270           2063          20177
Bourne Shell                     1              4              4             27
PowerShell                       1              1              0              5
DOS Batch                        2              0              0              4
-------------------------------------------------------------------------------
SUM:                           165           4275           2067          20213
-------------------------------------------------------------------------------

15-20 thousand lines of code without node modules being installed.

Further, in npm's case, the size with node modules is incredibly huge (yarn is about 1/6th the size in comparison):

$ ccd /tmp/npm && npm i npm && du -sh .
31M     .

What's more, you should also look at the platform abstract library that Node.js runs on top of - libuv. They have to emulate many parts of Unix on Windows for API compatibility,

---

While source code size isn't really a great indicator of what the program does, it's very clear there's a lot of surface area for things to be misused here.

In my opinion, it's not Microsoft's job to profile third-party applications and provide speed improvements - especially when those applications are written with several layers of abstraction between them and the operating system in question. Since this isn't showing proof that Node.js as a platform is slower, I would chalk this up to poor software design on the package managers' parts.

You should, however, definitely bring these findings up with the npm, yarn and node.js teams respectively, as they should be the ones spearheading a profiling initiative if one is really needed.

[asklar]

thanks for your input @Qix- ! To answer your question as to why this is a problem for Microsoft: it negatively affects the developer experience of a Microsoft product (one that I work on 🙂), React Native for Windows. Folks coming from a JS background or from a react native on android/iOS background are often disappointed with how slow these tools are which they have to use when they want to port their app to Windows, so we want to make it better for people writing apps for Windows :)
Thanks!

[Qix-]

Right, but just because something runs slow on windows, doesn't necessarily mean it's Microsoft's problem to solve. There are thousands of variables that could make it run slower. Unless you're arguing that Node.js as a platform, as a rule runs slower on Windows and not the individual applications built on top of Node (npm and yarn), then I don't see how this is a platform problem.

Npm is a fully-fledged company with funding and investors - if their commercial product is running slowly, they are fully capable of fixing it.

[warpdesign]

From my experience this appears to be related to disk performance and is not specific to npm: using npm to install new packages downloads and uncompresses lots of small files and Windows is not fast (to say the least) at creating lots of small files.

Disabling Windows Defender's real-time check mitigates the problem a little, but it remains very slow compared to other platforms (be it Mac or Linux).

[zooba]

I understand the arguments that everyone (that is, all the other package managers) could fix this themselves, but this is definitely in scope for what we want to be working on. We would rather fix as much as possible in the OS so that the benefits are "free", and then look at ways to help individual applications improve their own performance.

For example, we've been tracking Python and Git performance for a while now, and have already (quietly) released some updates that reduce overheads, which will naturally improve Yarn as well. We've also fed back some suggestions to the projects to help them improve things.

But we do believe that to a certain extent, POSIX code should be easy to port to Windows and maintain its performance. And since we're the only ones who can improve Windows itself, we're looking for ways to improve that "certain extent" before we turn back to giving advice directly to projects.

[bitcrazed]

Great issue, thanks for filing @asklar, and as @zooba says, this is indeed a great example of the kind of issue we're looking for!

It's quite possible that there's something in the implementation or port of node/npm/yarn that is inherently slow on Windows.

As I've discussed at length in other issues (e.g. #15), POSIX-first apps do tend to suffer on Windows, for a number of reasons. We're very keen to learn all the reasons why, and to figure out what can be done to reduce/eliminate the root-causes of the perf issues for such apps.

We believe we have a pretty good understanding of the key root-causes, but want to be sure we're not missing anything unexpected.

So, we're measuring problem scenarios (on normalized hardware to minimize hardware-specific differences) and are working to figure out the root-causes of perf issues such as this. We then plan to work out where best to fix the issue - be it at the node/npm/yarn/libuv end, or in Defender/Windows/etc. ... or both!

If the issue lays entirely/partly in an open-source project, we're happy to do our part as members of the open-source community to work with project owners and other community participants to implement a solid fix for the issues we find.

[nmoinvaz]

Why does it take so long to delete node_modules in Windows? It seems like the OS could just delete the directory file system record, instead of scanning some 90k files to prepare for delete..

[bitcrazed]

@nmoinvaz - are you trying to delete node_modules using File Explorer or from the command-line?

If the former, it's because File Explorer does a ton of work under the hood to enumerate & track all the files to be deleted, calculate and continually update estimated time to complete, etc.

Deleting these files from the command-line should be MUCH quicker:

• PowerShell: rm node_modules -force -recurse
• Cmd: del /s /f node_modules

[nmoinvaz]

Yes, in File Explorer. Part of the problem is if I accidently start deleting node_modules from the File Explorer dialog it takes a while to respond to even my cancel request.

Often times if a folder I am deleting is too big File Explorer, will ask me something like, "Folder is too big, deleting this will be permanent, do you want to continue?". Along the same lines, couldn't File Explorer ask me something like, "Folder has many files, do you want to quick delete it?"

[asklar]

@nmoinvaz I happen to have worked in file explorer for a number of years so I can tell you that often a "quick delete" is wrong in the context of the experience file explorer wants to give you. For example, file explorer needs to keep track of your often accessed locations/recently accessed files for showing them in Quick Access. Deleting a folder via file explorer means that now we have to go update the storage for this information, which takes additional time. The shell file operations engine is highly extensible, apps can register hooks to get notified when something changes, when files get deleted, etc. On top of that, as it was mentioned before, we have to do a first traversal to know how much stuff you have to know how to better estimate how long it will take. If you don't care about these features you can del or rd the folder as it was suggested.
Having said that, file explorer and features of the shell are outside the scope of this repo's issues :)

[zooba]

Having said that, file explorer and features of the shell are outside the scope of this repo's issues :)

Perhaps, but we've got file system folk handy (on internal threads) if there are ways we can change both sides at once. And I can't imagine any user being upset by delete (especially recycle) being quicker. We're not talking about milliseconds worth of improvements here, but minutes worth of "progress" which prevent the top-level folder name being reused until it's done (which is really what we want to do - the actual files can silently delete in the background over the next hour for all we care, provided we can put a different node_modules directory in its place).

@bitcrazed is the centre of the web, so he can pull together those responsible for a chat.

[nmoinvaz]

@bitcrazed should I file a new GH issue or no?

[bitcrazed]

@nmoinvaz - I was about to reply with a polite ask to please file new issues in their own issue rather than piggybacking on existing unrelated issues 😜

Please do file another issue and I'll summarize the points above in reply to your issue description.