99
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 22 Jun 2024
99 points (100.0% liked)
Rust
5633 readers
53 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
I did not read the whole conversation, but sorting seems a very common usecase (not mine, but seems to me a lot of people sort data), so this seems quite a broad improvement to me.
Note though, as is mentioned in the issue, that the survey showed people still prioritize runtime performance over compilation performance in general, so this tradeoff seems warranted.
It's not unheard of that regressions can be unmade later on, so here's hoping :)
Yeah, sorting is definitely a common use case, but note it also didn’t improve every sorting use case. Anyway, even if I’m a bit skeptical I trust the Rust team that they don’t take these decisions lightly.
But the thing that lead to my original question was: if the compiler itself uses the std sorting internally, there’s also additional reason to hope that it might have transitive performance benefits. So even if compiling the Rust compiler with this PR was actually slower, compiling again with the resulting compiler could be faster since the resulting compiler benefits from faster sorting. So yeah, fingers crossed 🤞
I would have assumed the benchmark suite accounts for that, otherwise the results aren't quite as meaningfull really. Which ties back you your 2nd senctence: I certainly trust the rust team more than myself on these things :)