-
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
Poor inlining of closures for vec::from_fn<T>() #6623
Comments
Seems to be fixed now, probably by #6881 |
For the record, I now get:
|
Actually, @huonw made me aware that extern mod extra;
use std::vec;
#[bench]
fn test1(b: &mut extra::test::BenchHarness) {
do b.iter {
vec::from_fn(1000, |_| 0);
}
}
#[bench]
fn test2(b: &mut extra::test::BenchHarness) {
do b.iter {
vec::from_fn(1000, |_| 1);
}
}
fn main() {
} Results:
|
Still very relevant, reproduces. |
Have you tried with |
I don't think I did, and I can't try right now, but I fail to see why that would possibly make a difference. The closures don't differ in their type signature but only in their constant return value. How would monomorphization make any difference? |
Oh, I see, you're right. |
I don't think this can be considered a bug, it's a consequence of only having boxed closures. |
See #8622 |
new lint: string-slice This is a restriction lint to highlight code that should have tests containing non-ascii characters. See rust-lang#6623. changelog: new lint: [`string-slice`]
Add Clippy version to Clippy's lint list Hey, hey, the semester is finally over, and I wanted to get back into hacking on Clippy. It has also been some time since our metadata collection monster has been feed. So, this PR adds a new attribute `clippy::version` to document which version a lint was stabilized. I considered using `git blame` but that would be very hacky and probably not accurate. I'm also thinking that this attribute can be used to have a `clippy::nightly` lint group which is allow-by-default that delays setting the actual lint group until the defined version is reached. Just something to consider regarding rust-lang#6623 🙃 This PR only adds the version to 4 lints to keep it reviewable. I'll do a followup PR to add the version to other lints if the implementation is accepted 🙃 ![image](https://user-images.githubusercontent.com/17087237/137118859-0aafdfdf-7595-4289-8ba4-33d58eb6991d.png) Also, mobile approved xD ![image](https://user-images.githubusercontent.com/17087237/137118944-833cf7fb-a4a1-45d6-9af8-32c951822360.png) --- r? `@flip1995` cc: rust-lang#7172 closes: rust-lang#6492 changelog: [Clippy's lint list](https://rust-lang.github.io/rust-clippy/master/index.html) now displays the version a lint was added. 🎉 --- Example lint declaration after this update: ```rs declare_clippy_lint! { /// [...] /// /// ### Example /// ```rust /// // Bad /// let x = 3.14; /// // Good /// let x = std::f32::consts::PI; /// ``` #[clippy::version = "pre 1.29.0"] pub APPROX_CONSTANT, correctness, "the approximate of a known float constant (in `std::fXX::consts`)" } ```
When there are multiple calls to
vec::from_fn<T>()
with the same typeT
but different closures, the compiler chooses to generate only one copy ofvec::from_fn<T>()
and pass the closure as an argument. This is really bad for simple closures like the ones invec::from_elem<int>()
orvec::to_owned<int>()
Running these gives:
But if I remove one of the functions and only keep the other, I get:
and
This causes a 10% performance hit for
rustc --no-trans
.0m14.664s
vs.13.592s
withfrom_elem
modified not to callfrom_fn
but having a literal copy of the code.The text was updated successfully, but these errors were encountered: