> Yes, and remember... optimizing for code size is optimizing for speed. =)

Not always. I think loop-unrolling is a common perf-optimisation technique. Even if the perf-gain is positive in this case, I highly suspect that it doesn't outweigh the cost of maintaining asm code(vs C/other higher level code).

edit: formatting

Yep. I remember loop unrolling the skeletal animation code in libgdx way back resulted in a significant performance increase. And that was in Java

More so inlining. Much more than loop unrolling.

Optimizing for size is a local maximum in performance.

Less code doesn't imply faster code. GCC coreutils have blasted through openbsd coreutils for years.

Now we have CPUs with 256KB instruction cache and up. You can compile your whole OS at insane optimizations.

There are some LLVM optimization talks that show otherwise, where longer vectorized code actually runs faster than the smaller version, though.

...in microbenchmarks.

That's what created multi-kilobyte memcpy() implementations, which barely beat REP MOVSB but cause huge icache bloat.