4 ms·

For each input source file, cl.exe creates at least 7 temporary files (with suffixes "gl", "sy", "ex", "in", "db", "md", "lk"). The churn of creating and deleti

by pbsd 7y ago

For each input source file, cl.exe creates at least 7 temporary files (with suffixes "gl", "sy", "ex", "in", "db", "md", "lk"). The churn of creating and deleting those, coupled with the slowness of performing checkpointing on a huge empty drive, seem to be the root cause here. This appears somewhat related to this bug report: https://developercommunity.visualstudio.com/content/problem/310131/clexe-creates-so-many-temp-files-it-freezes-the-sy.html https://developercommunity.visualstudio.com/content/problem/... Marking the temporary files as FILE_ATTRIBUTE_TEMPORARY could improve things, without having to go into significant Windows kernel changes.

snagglegaggle 7y ago
> Marking the temporary files as FILE_ATTRIBUTE_TEMPORARY could improve things, without having to go into significant Windows kernel changes. Having used Cygwin and MinGW (and less so WSL) NTFS is probably the main factor here. Especially when using Cygwin program compilation is very slow not just due to process creation but file access, potentially on disk. I could see checkpointing contributing, but having used backups/file history on Windows server, you will see CPU use irregularities that I think are similar in cause to this but you do not see CPU use irregularities as bad as described in the article. The pathological behavior of NTFS with many files is easy to prove once you encounter it.[0] This would be exposed to the kernel as well and is likely holding up NtfsCheckpointVolume. At least in my experience the problem goes deeper, and how NTFS structures are handled also contributes; for example, trying to enumerate and copy files in certain ways is extremely slow even if the files are easily enumerable. You can say that if disabling checkpointing gets rid of noticeable slowdown it is the right thing to do, but there are people who will rightly not want to disable it. [0] https://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories https://stackoverflow.com/questions/197162/ntfs-performance-...
- pault 7y ago
  Time the difference between an npm install, with all its thousands of tiny files, on NTFS and ext4. It's excruciating.
  - cpach 7y ago
    Just copying Emacs for Windows from one folder to another takes surprisingly long time :)
- Filligree 7y ago
  I've definitely noticed this behaviour. It's excruciating. There's a ZFS driver for Windows now. I haven't tried it yet, but I think I will. Can't be any worse.
NullPrefix 7y ago
> Moving %TEMP% to a RAM drive made the builds noticeably faster and also left the system responsive, even during two concurrent 20-way parallel builds (40 compile jobs in parallel, no loss of system responsiveness). This matters more than anything else. You can play all you want with FILE_ATTRIBUTE_TEMPORARY or whatever else markings but the OS will just not care about them enough.
- MuffinFlavored 7y ago
  Does creating a RAM drive in Windows still require third-party software/drivers or is it natively supported by Microsoft these days? I haven't tried to do it since Windows 7 I believe.
  - pdimitar 7y ago
    AFAIK, it still requires 3rd party software. However, having a Samsung SSD and enabling RAPID mode in Samsung Magician (SSD management software) which effectively uses an invisible RAM disk accelerated my games' startup times by a factor of at least 3x. Some games even start 5x times faster. I do recognise that games have a much different workload than compiler jobs of course; but invisibly utilising a RAM disk might help a lot regardless.
  - NullPrefix 7y ago
    That whole Linux integration into Windows marketing campaign could have you believe that Linux things just work on Windows now and you can just "mount -t tmpfs none /path/to/my/mount -o size=64G". I doubt that is going to happen. File system mounts do not run on marketing fuel.
    - jrockway 7y ago
      The latest variant of WSL uses a VM. So that will work, but you won't be seeing that mount inside Windows.
      - Dylan16807 7y ago

by pbsd 7y ago

snagglegaggle 7y ago

> Marking the temporary files as FILE_ATTRIBUTE_TEMPORARY could improve things, without having to go into significant Windows kernel changes. Having used Cygwin and MinGW (and less so WSL) NTFS is probably the main factor here. Especially when using Cygwin program compilation is very slow not just due to process creation but file access, potentially on disk. I could see checkpointing contributing, but having used backups/file history on Windows server, you will see CPU use irregularities that I think are similar in cause to this but you do not see CPU use irregularities as bad as described in the article. The pathological behavior of NTFS with many files is easy to prove once you encounter it.[0] This would be exposed to the kernel as well and is likely holding up NtfsCheckpointVolume. At least in my experience the problem goes deeper, and how NTFS structures are handled also contributes; for example, trying to enumerate and copy files in certain ways is extremely slow even if the files are easily enumerable. You can say that if disabling checkpointing gets rid of noticeable slowdown it is the right thing to do, but there are people who will rightly not want to disable it. [0] https://stackoverflow.com/questions/197162/ntfs-performance-and-large-volumes-of-files-and-directories https://stackoverflow.com/questions/197162/ntfs-performance-...

pault 7y ago
Time the difference between an npm install, with all its thousands of tiny files, on NTFS and ext4. It's excruciating.
- cpach 7y ago
  Just copying Emacs for Windows from one folder to another takes surprisingly long time :)
Filligree 7y ago
I've definitely noticed this behaviour. It's excruciating. There's a ZFS driver for Windows now. I haven't tried it yet, but I think I will. Can't be any worse.

NullPrefix 7y ago

> Moving %TEMP% to a RAM drive made the builds noticeably faster and also left the system responsive, even during two concurrent 20-way parallel builds (40 compile jobs in parallel, no loss of system responsiveness). This matters more than anything else. You can play all you want with FILE_ATTRIBUTE_TEMPORARY or whatever else markings but the OS will just not care about them enough.

MuffinFlavored 7y ago
Does creating a RAM drive in Windows still require third-party software/drivers or is it natively supported by Microsoft these days? I haven't tried to do it since Windows 7 I believe.
- pdimitar 7y ago
  AFAIK, it still requires 3rd party software. However, having a Samsung SSD and enabling RAPID mode in Samsung Magician (SSD management software) which effectively uses an invisible RAM disk accelerated my games' startup times by a factor of at least 3x. Some games even start 5x times faster. I do recognise that games have a much different workload than compiler jobs of course; but invisibly utilising a RAM disk might help a lot regardless.
- NullPrefix 7y ago
  That whole Linux integration into Windows marketing campaign could have you believe that Linux things just work on Windows now and you can just "mount -t tmpfs none /path/to/my/mount -o size=64G". I doubt that is going to happen. File system mounts do not run on marketing fuel.
  - jrockway 7y ago
    The latest variant of WSL uses a VM. So that will work, but you won't be seeing that mount inside Windows.
    - Dylan16807 7y ago