4 ms·
I noticed in one of my crates that Rust often cannot optimize "moves" away. I was in the unusual situation where I had to move around a very large stack buffer(
by nu11ptr 4y ago
I noticed in one of my crates that Rust often cannot optimize "moves" away. I was in the unusual situation where I had to move around a very large stack buffer(typically in Rust they live on the heap). Instead of passing it back and forth between moving functions as I originally designed, I had to redesign it to use macros which significantly improved my benchmarks. Further attention to optimizations here would be very welcome.
- redanddead 4y agoHow did you implement those macros?
- nu11ptr 4y agoTbh it was like a year ago and I forget the specifics. You are welcome to look at the code, however: https://github.com/nu11ptr/flexstr/blob/master/flexstr/src/builder.rs#L194 https://github.com/nu11ptr/flexstr/blob/master/flexstr/src/b... UPDATE: As I'm thinking about it, it is starting to come back to me a little: 1. I create the buffer 2. I do some op against it to fill it 3. I consume it and transform it into a final immutable flexstr For #1, the 'new' function moves the buffer back to the caller (memcpy). Using it in #2 I think was fine as I think it is typically passed by mutable ref. For #3, the buffer was moved again (passed by `self`) so it could be consumed and reused without a language level copy (but was copying in the generated code). Replacing #1 and #3 with macros kept the stack buffer in the local stack frame and greatly sped up my code in benchmarks, and that is what those two macros do I linked to if I'm recalling correctly.