-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Compiling "Hello World" can take a prohibitive amount of time #3216
Comments
Yeah. This is something we need to spend some time on before 0.4; it's sufficiently bad that we're seeing people landing a lot of code (myself included) without completing a full testsuite run. Because it takes too long. That's not cool. (Not to say that the various improvements in the compiler that have cost it performance were bad ideas! Just that it seems like there's some cost to mop up) |
oh, wow, i thought the increased times to build libcore and libstd were my fault for adding so much code to them. fwiw, last time i ran -Z time-passes building one of these i remember LLVM being slower than any other pass by a factor of 20 or so. |
non-critical for 0.6, de-milestoning |
Yes, there is still too much metadata reading. |
Today, this takes ~250ms to compile. The worst offenders are:
Note that this is also an incredible pain point for Nominating for production-ready |
accepted for production-ready milestone |
This is |
Dupe of #4572 |
Update bytecount to 0.4, and use its generic feature. Closes rust-lang#3216.
Fix x86 SSE4.1 ptestnzc Fixes ptestnzc by bringing back the original implementation of rust-lang/miri#3214. `(op & mask) != 0 && (op & mask) == !ask` need to be calculated for the whole vector. It cannot be calculated for each element and then folded. For example, given * `op = [0b100, 0b010]` * `mask = [0b100, 0b110]` The correct result would be: * `op & mask = [0b100, 0b010]` Comparisons are done on the vector as a whole: * `all_zero = (op & mask) == [0, 0] = false` * `masked_set = (op & mask) == mask = false` * `!all_zero && !masked_set = true` correct result The previous method: * `op & mask = [0b100, 0b010]` Comparisons are done element-wise: * `all_zero = (op & mask) == [0, 0] = [true, true]` * `masked_set = (op & mask) == mask = [true, false]` * `!all_zero && !masked_set = [true, false]` After folding with AND, the final result would be `false`, which is incorrect.
I've noticed recently that the compilation times of even trivial programs has become relatively large. This is most noticeable in the context of my sort-of-REPL, which now exhibits noticeable pauses between entering commands due to constant recompiles. On my beefy desktop, compiling the standard HW:
takes around 0.4 seconds. I've spoken with @pcwalton briefly about this and he's acknowledged the issue and mentioned that he has ideas to mitigate it.
Here's a more severe case: a fellow on IRC (MattCoder) has noted that on a Windows XP virtual machine, Hello World takes more than a minute to compile. The machine is an Intel Core 2 Quad CPU Q8400 @ 2.66Ghz with 4GB RAM, and the virtual machine itself has 2GB. It should also be noted that the virtual machine runs VS2008 comfortably and compiles C and C# programs in the negligible time you would expect: http://postimage.org/image/o9y6d1znl/
The text was updated successfully, but these errors were encountered: