I've made some code to automatically PGO the Nim compiler quite a long time ago, but never got to actually get something useful out of it until now :)
If you don't know, PGO allows you to profile programs on real data and then feed that profile to the compiler (the C compiler in our case) so it can decide how to optimize code based on real program usage. So, here's a small post made with nimib that shows the difference in compiler timings (with `--compileOnly`, obviously no C compilation step) between different versions compiled with GCC/Clang with release, danger, release + lto, danger + lto, danger + lto + pgo (didn't bother to make release + lto + pgo, sorry). [Read it here](https://rawcdn.githack.com/Yardanico/nim-snippets/10efae669295a577d457b6c7f3364d6aa71cec74/pgo/plot_results.html), source - [in my nim-snippets repo](https://github.com/Yardanico/nim-snippets/blob/master/pgo/plot_results.nim). That folder also has all other files used to actually compile the compiler binaries and benchmark them. If you don't want to read the full post, the TL;DR is (YMMV): * GCC is faster than Clang for normal compiler binary (with `-d:release`) * Clang is faster than GCC if you're using LTO or LTO + PGO * Average Nim compilation speed-up factor is ~1.7x with the fastest-performing Clang + PGO binary Funnily enough, the graphs are mostly consistent, with speed-up factors being constant regardless of the project (even if it wasn't in the profiling data). I think that PGO'd compiler might be useful if you have a big enough project that even the Nim stage takes a long time, or if you want to have your development iteration cycle be as fast as possible. If you want to PGO your own program (which might be much more useful than PGO'ing the compiler), see the `compile_pgo.nim` file in the repo or read <https://forum.nim-lang.org/t/6295> (simpler but more manual process). And regarding LTO - just always use it for release builds unless it makes your program slower or creates weird bugs - it's free performance for your users.
