No. TFA points out there isn’t a gigantic performance sink or anything, just an infelicity in the code they’re generating.
>> Does this mean Rust is slower than C++?
> No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.
As pointed out elsewhere in this comment tree, things living on the stack when they needn't can mean they don't fit and thus the program doesn't work, so the optimisation can matter for that reason, and this is a particular reason to worry about it for larger objects where the optimiser is more likely not to see what's going on.
And yet, real world production rust programs exist and measured performance is generally excellent.
People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds, when even with these excess copies we already know, and have known for years how rust programs have been performing in real life.
That there is room for improvement here does not mean that the status quo was not already excellent.
>> Does this mean Rust is slower than C++?
> No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.