| > I've heard tons of people complain about slow compilers, A slow compiler does not imply the compiler is slow because there's thousands of bespoke optimizations for nonsense code being ran > Also, if you think about it, optimising code has to follow diminishing returns, Nope, trivially. Though, I'm always eager for a Fermat-style marvelous proof that may have been too big for the initial margin you had. :) Take a classic case of a buggy compiler generating O(n²) temporary copies due to missed alias analysis. One optimization pass to fix that analysis transforms it to O(n). > at some point we are putting too much CPU time into little to no gains It is theoretically possible to design a compiler such that it spends much more time looking for optimizations that the total sum of looking is greater than the program it is optimizing's runtime. For example, an optimizer that is a while loop that checks if the function returns 42, but the function returns 43. I'm not sure what light that sheds. I'm not sure that implies that compilers have tons of bespoke optimizations for hand-transforming specific instances of absurd string code. If they do, I would be additionally surprised because I have never observed that. What I have observed is compilers, universally, optimize code structures of a certain general form > This is why there's -O3 in gcc and it's not the default, there's a cost to it that's likely not worth paying. The existence of an argument with a higher processing level than default does not imply the compiler is slow because there's thousands of bespoke optimizations for nonsense code being ran. (n.b. -O3 is understood, in practice, to be risky because it might be too aggressive, not that it might not be worth it) |