Interesting article. I enjoyed it. I have two thoughts. ==== 1. Regarding the benchmark itself, I wonder out loud if CPU caching could have a meaningful alte

Interesting article. I enjoyed it. I have two thoughts. ==== 1. Regarding the benchmark itself, I wonder out loud if CPU caching could have a meaningful alter on the results. The article says : > I randomly generate 4000 spheres, capsules, segments, and triangles. It is not clear to me if this is enough to fill CPU L1 cache or not. My guess is that it is not. If all the benchmark indeed happens within the L1 cache, I wonder how a bigger workload would affect the results. Maybe it does not change anything. But maybe it does. ==== 2. The author mentioned two criterion for choosing between by-copy and by-borrow : performance and ergonomics. I would add a third, somewhat related to ergonomics : let's call it semantics. When some piece of data naturally belongs somewhere and some others entities are natural "readers" of it, it might make sense to use the ownership / borrowing mechanism of Rust to naturally reflect this relationship, regardless of performance or code ergonomics. In particular, a borrow guarantees you always work on a read-only, up to date value of the data. Meanwhile, after a pass by-copy the life cycles of the data seen by the caller and the data seen by the callee become independent of each other. This can have consequences, particularly in a multi-threaded environment.