My own experience with clone and its costs were different - cloning did affect the performance significantly, and avoiding that boosted performance significantly! So it really depends on the application itself.
Yes, that ultimately comes down to how hot the code path is and the asymptotic complexity of the `clone` method itself, which are very much influenced by the nature of your application.
What we're saying is that, in the context of "fast development", it's a beneficial mental model to treat cloning as cheap and expendable, *until proven otherwise*.
Perhaps a direct corollary here is that it would generally be a good idea to design your datastructures *such that* clones are as cheap as possible (e.g. by making it shallow), since `Clone` is such an integral part of Rust ownership model. That way you set it up so you can use clone "guilt-free" to satisfy the borrow checker, while relegating the deep copy to an explicit method for those (much rarer) cicurmstances that needs it.
Very nice writeup! Loved everything about it.
My own experience with clone and its costs were different - cloning did affect the performance significantly, and avoiding that boosted performance significantly! So it really depends on the application itself.
Yes, that ultimately comes down to how hot the code path is and the asymptotic complexity of the `clone` method itself, which are very much influenced by the nature of your application.
What we're saying is that, in the context of "fast development", it's a beneficial mental model to treat cloning as cheap and expendable, *until proven otherwise*.
Perhaps a direct corollary here is that it would generally be a good idea to design your datastructures *such that* clones are as cheap as possible (e.g. by making it shallow), since `Clone` is such an integral part of Rust ownership model. That way you set it up so you can use clone "guilt-free" to satisfy the borrow checker, while relegating the deep copy to an explicit method for those (much rarer) cicurmstances that needs it.