I can, see below. But since when has it been suggested to reduce the number of local variables in C/C++ to increase performance?
If they are not local variables on the stack then they are going to be on the heap, which I don't think can be faster as that requires a pointer dereference and will require allocation and decalocation.
Or they are globals, which is generally bad practice and probably does not gain much performance if any.
Historically the C/C++ world has been full of helpful advice, micro-optimizations, intended to increase performance. Most of it is obsolete and does not work in the modern world. Modern compilers can do a much better job of rearranging code for speed than most programmers can even if they are coding in assembler. Processors are full of optimization tricks like executing instructions in parallel, reordering operations, predicting branch directions and so on.
Optimization today is far more about ensuring the data you are working on is found in cache as much as possible. Which is a good reason to avoid OOP for performance critical code.
Security and safety is another matter. A you know Rust provides memory safety and freedom from race conditions between threads. That goes a long way to ensuring security but of course there are all kind of ways you can write insecure code even in a "safe" system. Security is not my expertise so I will leave it at that.
When it comes to Rust performance I have found that I can always match or even beat the speed of C for the same functionality using the same algorithm. A few things I picked up along the way:
Rust does bounds checking on array indexing for memory safety. Often that can be checked at compile time, often it has to be checked at run time because of the way you have written your code. Be sure to help the compiler. By iterating over slices rather than writing C style "for" loops and indexing things can go much faster as the compiler creates the indices and so does not have to range check them on every iteration
Use fast_floats: https://docs.rs/fast-floats/0.1.2/fast_floats/ Turns out that with that and 1) above the compiler can vectorize things nicely.
Beware of those who offer "functional" style solutions to your performance problems. I have found they can often be verbose, obfuscated and not much faster if any. Sometimes the functional style in Rust is just not the way to get performance. But when it is things can really sing!
Beware of those who suggest use of "unsafe" for performance. I like to avoid using "unsafe" in my application code. I has turned out that "unsafe" has never been required to match the speed of C in the problems I have tackled.
You might like to look at, at run, a couple of my experiments where I have all kind of Rust solutions trying to match C speed for some function, suggested by forum members. It's interesting to see what gets performance and what does not: