Installing rust-docs component on Windows 10 is very slow #1540
Comments
|
CC @retep998 |
johnthagen
changed the title
johnthagen
changed the title
|
I did timed sample run: All of the other components installed in a mater of a couple seconds, but This is on a Windows 10 machine with a quad core i5 @ 4GHz and an SSD. All 4 cores are pegged up at around 60-80% for the duration of the install. |
|
It appears that Windows Defender is definitely involved, based on a CPU usage capture during the install of
|
|
Yes, Windows Defender does cause significant slowdowns - however, turning off real time protection doesn't help very much - it still takes forever. Maybe I should be doing something more than just disabling real time protection? At this point I'm seriously annoyed - multiple people have opened issues for this, and suggested changes such as making the doc optional, merging the small files in the doc into a few large files to accommodate for slow file systems, etc - nothing has really been done so far except "disable your antivirus". |
@ndrewxie Could you please link those issues to this one? I opened this because I thought it hadn't been officially reported yet. Best to link any previous discussions together. |
|
At this point I think the only fair thing to do is make |
As a polyglot Windows and Mac user, I do feel sometimes that Windows support lags behind Linux and Mac in subtle ways (like this issue, for example), but I'd like to try to keep this issue focused on this particular issue, and the concrete ways the situation can be improved. |
|
I'm normally a Linux user, but found myself trying to do some project work on Windows today and my god is everything slow. Are there concrete reasons why creating lots of small files (which I'm not super familiar with how Windows does things like its filesystem and Windows Defender under the hood, but I'd be keen to help out. Besides telling all Windows users to turn off their antivirus are there any other ways to mitigate this poor performance? It sounds like we're not the only community suffering from poor filesystem performance because people have had the same issues with |
|
It is also slow if you install Rust in WSL. Filesystem is just very slow on Windows. I would prefer to not install docs if it was possible. |
|
Another data point from @chriskrycho:
|
|
More discussion on this internals thread. Issue previously reported: #763 Issue to make rust-docs optional: #998 @nrc Appears to be working on profiles to help address this: #998 (comment) |
|
The |
|
I've been looking at the rustup code to see how it works with files. If I understand correctly, updating a component is performed in a transaction where each original file is moved to a temp folder before the new file is written in its place. I was wondering if it would be viable to simply rename the toolchain folder? That would significantly reduce the number of file operations to perform. However, this would only work for toolchain updates, not component installation/removal. That said, installing a new toolchain (i.e. not updating) is slow as well, so this may be a red herring. |
|
A related issue reported on the User's Forum and #1464:
|
|
Another data point. Building a https://travis-ci.org/johnthagen/min-sized-rust/builds/465623377
|
|
What if rustup would install |
|
The sources are still 2,307 files. While not as bad as the 15,377 files of the docs, it's still a hefty chunk of time. Really we should just not extract |
@retep998 This seems very reasonable, and I agree with @kryptan that most users will never use What would be the workflow envisioned for this? Something like the following? $ rustup install toolchain X
... (installs rust-docs compressed file, but does not extract)
... (some time later)
$ rustup component add rust-docs
... (this extracts the rust-docs compressed file, so works even without an Internet connection) |
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
|
I think this is a strict duplicate of #904 - the rust-docs component shows the pathology most severely, but its not unique to rust-docs. |
|
@rbtcollins Even if we had perfect disk access, installing |
|
Windows Defender who is the principal contributor to this issue, is spinning up whole arbitrary file type parsers between system calls, there's nothing to do about it but to change Windows Defender and thus Windows, who has it enabled by default. I understand the problem of using a monolithic system where any program gets access to the whole filesystem without an Anti-Virus, but it's not like we can't do better than monolithic these days. As a workaround, I would be looking at trying to extract the file in a way that Windows Defender can clearly recognize the relationship between it's archived copy and it's extracted copy, Windows Defender will scan archives when they are written already, if it can identify that the file is being copied out of an archive it already scanned, it does not need to scan it again. You might want to use a third party tool for this, a third party tool that is trusted by Windows Defender, that most commonly happens when it has a digital signature with some history of having good behavior. Windows might have some command line tools to extract archives. |
|
To clarify, as rustup executables lack digital signatures, they're considered unknown and potentially suspicious by Windows Defender or other Anti-Viruses and stricter active scanning rules are being applied on them. A file without a digital signature could end up being considered trusted, but it takes more time, an employee needs to go and attest that the executable is trusted and register it's hash to the database. With digital signatures, the process is more of an habit. Companies get reputation through their digital signature, if they misbehave, the whole signature is marked as suspicious. Digital signatures come in limited supply. Malware is less likely to have access to digital signatures, newly created ones don't get trust so early, some new software that has no malicious behavior must first appear for the Anti-Virus to start trusting it. Then digital signatures that get stolen, it's another story, it can cause quite an amount of damage because Anti-Virus will turn blind eye for some time, but eventually companies learn to protect their systems to avoid that and the event becomes rarer. |
|
@Leo-LB you may be interested to know that the performance work I'm doing is improving performance when Defender is disabled / excluded on the rustup directory: When I started doing this optimisation work with defender disabled and indexing disabled, rust-docs installation was nearly 40 seconds: I've pulled it down to 10 seconds. Yes Defender's overhead is a significant factor as well: There is a work item in the rustup community to have rustup's distribution be signed, but I haven't been involved in that, and even with that made completely optimal there was a lot of poor behaviour we had to fix - see above. |
|
@rbtcollins Okay, well good work on that. Rather than signing rustup binaries themselves, you could ship rust docs in .zip format and make use of a command line tool shipped by default in Windows to extract the archive. |
|
Rather than ZIP, I would use CAB files, because there is better supported tools installed by default for it since early Windows days. See https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh875545(v=ws.11) and https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/expand Also, the standard installation mechanism on Windows is MSI, so that'd be the best. Packaging either Rust as a whole in an MSI, or only for docs, and then install that MSI. |
|
You have little hope at staying in the FOSS world for your toolchains and build systems if you are using Windows, else you'd be suffering quite big constraints like this performance one. |
|
https://en.wikipedia.org/wiki/WiX is the only FOSS that can create MSI Windows Installers, CAB file can be read but not created by FOSS. |
|
I'm now involved in a discussion with Defender folk ; they've asked for traces of the poor behaviour. Please use rustup 1.18.3 or newer, nothing older, as there is no point sending in unoptimised traces IMO. We only need 3-4 traces from a few different machines where Defender overhead is the problem; I'll be submitting one from a surface pro and one from a 2990WX. If someone has a machine with e.g. spinning metal disks, or even less cores or whatever - something interestingly different, please add the trace id here. For us the use case we're tracing is unpack performance, so I'd suggest running rustup uninstall nightly, rustup install nightly waiting for it to start installation, then copy the contents of ~/.rustup/downloads/* to a temp dir. The rustup uninstall nightly. Then copy that temp dir contents back to the the downloads dir. Finally, start the trace and then run rustup install nightly. Instructions for gathering a trace (note this captures most metadata about what the system is doing..):
|
|
@rbtcollins feedback-hub:?contextid=242&feedbackid=953429f7-8755-4abb-ae7b-26cb61729786 I have my
non-OS HDD drive ( |
|
This is my trace from my 2990WX |
|
@CAD97 do you perhaps have the console output? e.g. something like
If you didn't see the above, you were running an older, single-threaded rustup |
|
My surface pro trace - |
|
@rbtcollins Didn't record the console output directly, and Feedback Hub seems to not have preserved the screenshots in a user-visible way. Output was inded of the format I added another trace to my report after confirming that I am running |
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
Due to rust-lang/rustup#1540, installing the docs on Windows can be slow enough to time out a fresh rustc install. Marking this `Command` as `quiet` increases the timeout.
|
With 1.20 you can set the profile to minimal and obviate the need to install |
|
I agree that the form of rust-docs remains an issue, but it's not specific to Windows (though we are a lot better now providing you're not using something like McAfee) and any mitigations we come up with will need to be cross-platform or potentially something which changes how the rustdoc itself is generated. |
|
I remember watching some video based on this issue about io performance and ms defender. Can anyone send link here please? |
@uis246 Are you looking for https://lobste.rs/s/yne5kz/ntfs_really_isn_t_bad_robert_collins_lca? |
|
@rami3l Yes, thank you. |
|
I also meet this problem in linux, |
As reported on the User's Forum, installing the
rust-docscomponent on Windows 10 is currently very slow compared to other components, even on machines with an SSD and multi-core processor.The text was updated successfully, but these errors were encountered: