4 ms·
Sure, but that's a performance vs ease of use decision. Often you don't need to care about the extra allocations and can just deserialize to owned types. The
by the_duke 6y ago
Sure, but that's a performance vs ease of use decision.
Often you don't need to care about the extra allocations and can just deserialize to owned types.
The code for owned deserialization certainly ends up looking more elegant.
- throwaway894345 6y agoIt’s not just performance, but you now have to go back and update every instance of that struct to reflect the change in ownership of that member if you can even change the member in the first place (e.g., you can’t change the type of a member of the struct itself is defined in a third-party package). Moreover, some instances of your struct might be in a tight loop and others might not, but now you’re committing to poorer performance in all cases. Maybe you can box it (although IIRC I’ve run into other issues when I tried this) but in any case this isn’t the “elegance” I was promised. Which is fine, because Rust is a living, rapidly-improving language, but let’s not pretend that there is an elegant solution today.
- fasterthanlime 6y agoLibraries can be (and some actually are) designed with that in mind, with COW (copy on write( types that can be either borrowed or owned. Speaking of performance, kstring (of liquid) goes one step further with inline variants for short strings. I want to say that seems like a valid concern but in practice I've seen it come up only rarely.