On Fri, 29 Oct 2021 at 10:36, Eliot Moss <m...@cs.umass.edu> wrote: > I think a lot of us know that fork() under Cygwin is slower than on Linux and > have some grasp of why. But I have noticed that file access is rather lower > under Cygwin as well. My "poster child" for this is running latex. I am > working on writing a book, which includes a huge number of LaTeX style files > and such. Under WSL1 (which has the same fork cost issues as Cygwin for > similar reasons), reading the style files goes by in little more than the > blink of an eye (about 1 sec), while on Cygwin it takes a little over 17 > seconds. > > The time to process the body of the book is 23 seconds under WSL1 and 35 under > Cygwin. So the total times are 53 seconds under Cygwin and 24 under WSL1. I > believe the LaTeX installations are the same versions, and I get the same > outputs. Both LaTeX's are 64 bit programs. There is not much forking here > (at least I don't believe there is, but maybe there is under the cover for > doing things with pdf figures or something), but a fair amount of file I/O. > > For many / most things, the Cygwin overhead is tolerable; for running this > book, since I will be doing it over and over, it was worth investing in > getting everything set up on WSL1. > > But it got me wondering as to why?
AIUI it's a fundamental part of the trade-offs that NTFS makes: compared to common Linux file systems like ext4, NTFS is much slower at things like parsing directory structures (which is a necessary part of opening any given file). In the same way that native Windows programs tend to use threading implementations that work differently to fork(), native Windows applications will also often much prefer large monolithic data files, where native *nix applications are much more likely to have lots of small files. As a result, for things that require opening lots of files, WSL (at least if you're using the native WSL disk, which will be a *nix disk image stored in a file, rather than files under /mnt/c or similar) will likely be quicker than a similar operation through Cygwin, as Cygwin will always be affected by those NTFS overheads. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple