> A switch statement with many cases can be compiled as a jump table (fast, O(1), but requires a full table load and indirect jump) or as a cascade of compares (slower per-case but better branch prediction if one case dominates).<p>Switch case is the workhorse of a lexer, parser and execution engine. Lots of them over enums.<p>This was all mis-optimized for years thanks to Spectre/Meltdown changing how the actual runtime of pre-fetch and speculation used to work.<p>All my work on CGOTO was made irrelevant by the CPU advances, only to become relevant again when fetch speculation got nerfed.<p>The indirect call scenario is a bit more interesting, because the JVM has an amazing paper about interface dispatch caches [1] on how to do it runtime instead of compile time.<p>The PGO is still useful, but not unless you can predict the workload you're going to have - Benchmarketing with a TPC benchmark is a good situation for it.<p>If you have consistent hardware, tuning an OLTP system for the hardware is much more interesting. Going back in the memory hole, Yahoo used to have a Jeremy Cole build of Mysql which was specially optimized for the raid disk layout that was in production (ZFS came by to fix those issues directly).<p>[1] - <a href="https://dl.acm.org/doi/10.1145/504311.504291" rel="nofollow">https://dl.acm.org/doi/10.1145/504311.504291</a>