It is not at all counterintuitive. The compiler has no model of CPU cache so it is completely oblivious of the effects of various optimizations on caching perfo

It is not at all counterintuitive. The compiler has no model of CPU cache so it is completely oblivious of the effects of various optimizations on caching performance. Most of the time the optimizations work as advertised but there is no problem contriving examples that show ridiculous improvements by removing speed optimization. There are various limits that have huge effect on your code performance. For example, if your inner application loop does not fit instruction cache its performance might be impaired. If you can reduce the size of the code, ironically by removing speed optimizations, this might just be what is needed to dramatically speed it up. On macro scale years ago I have been using Gentoo and, generally, compiling almost everything with size optimization had very positive performance improvement on a platform that has been deficient in RAM. I guess "size" improvement should not be thought as opposite of "speed" improvement but rather an alternate way to possibly improve performance. The compiler does not know which alternative may or may not bring effects.