I'm not a game dev but work in a scientific field. One thing I didn't see mentioned here which may or may not be relevant is it pays to try to keep your memory footprint as low as possible. Memory I/O is a bitch. So for example, let's say you have 2 vectors that interact in some way. You may be tempted to store precalculated interactions in a matrix, but generally speaking, it's best not to do this. Just calculate each cell of the matrix on the fly as you need it, even if it's a long formula and you need to access this same value many times. 2 vectors are more likely to fit in L1 cache and you'll get the best performance out of all the compiler optimizations. It makes a huge difference.

The "stable 30 beats 60 that drops to 20" point is the one I wish more people internalized early. Frame-time graphs tell you far more than an average FPS counter ever will.

Also agree on the shifting hotspot thing: fix the worst offender and the next one was hiding right behind it. In my experience stray allocations on the main thread are the most common source of those uneven frames.

Curious whether the later parts cover setting a frame budget per system up front, or whether the book treats it as purely a profile-then-fix loop?

(links no good for me)