Leaving performance on the table

This is a great example of why you should be super careful about PGO: Fibonacci is very unlikely to be representative of the kinds of queries that you normally run on SQLite. How many queries does a normal SQLite user do that recurse a hundred million times?

The result of this exercise is almost certainly a version of SQLite that is so overfitted to running Fibonacci that it's slower than the default build for most normal workloads. And it's still a very slow way of running Fibonacci.

The same is true for static annotations. I recall a study on an old version of Linux that found that performance improved if you removed all of the likely and unlikely annotations.

I would expect LTO to do almost nothing here: they’re using SQLite’s “agglomeration” distribution, which puts all the code in one C file, whereas LTO’s benefits are exclusively across C files. I believe this is done both for convenience of embedding, and as a crude replacement for LTO.

(In theory, LTO could still provide a benefit if they’re statically linking to libc. But that’s not the case here.)