Yup. If that 12-cycle speedup is in a hot loop, then yeah, throw a bunch of comments and tests around it and perhaps keep the "clean" version around for illustrative purposes, and then do the fast thing. Perhaps throw in a feature flag to switch between the "clean" and "fast but a little sketchy" versions, and maybe someone will make a method to memoize pure functions generically so the "clean" version can be used with minimal performance overhead.

Clean code should be the default, optimizations should come later as necessary.

For what its worth , the cache locality of Vec<Box> is terrible in general, i feel like if youre iterating over a large array of things and applying a polymorphic function you're making a mistake.

Cache locality isnt a problem when youre only accessing something once though.

So imo polymorphism has its place for non iterative-compute type work, ie web server handler functions and event driven systems.

Loop unrolling is not really the speedup, autovectorization is. Loop unrolling does often help with autovectorization, but is not enough, especially with floating point numbers. In fact the accumulation operation you're doing needs to be associative, and floating point numbers addition is not associative (i.e. (x + y) + z is not always equal to (x + (y + z)). Hence autovectorizing the code would change the semantics and the compiler is not allowed to do that.

I wonder if the compiler checks to see if the calls are pure and are therefore safe to run in parallel. It seems like the kind of thing the Rust compiler should be able to do.

Do you mean this for loop?

for shape in &shapes {
  accum += shape.area();
}

That does use an iterator

for-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common practice within Rust, which is to loop over anything that implements IntoIterator until the iterator returned by .into_iter() returns None (or the loop body uses break).