The "guard" trick from JITs (including PyPy)

Posted Aug 11, 2025 9:08 UTC (Mon) by farnz (subscriber, #17727)
In reply to: The "guard" trick from JITs (including PyPy) by euclidian
Parent article: Python performance myths and fairy tales

The most trivial fix that works is to put the guard next to the access, rather than at the beginning of the function.

You can then test the guard inside the optimized code, and continue in the optimized path if it passes, or switch back to the slow path if it fails. You'd usually have the "guard failed" path be the one that saves state ready for the slow path - so optimized with guard passing can keep things in registers, but if it ever fails at runtime (e.g. you optimized based on the value of a global, that global has changed), you store everything and switch back to slow path.

There's more complex options, of course, but that's the simplest; indeed, in the literature relating to guard motion and elision, it's sometimes assumed that you'll place a guard next to each place where you depend on a guarded assumption, and then depend on being able to show that moving the guard earlier (and possibly combining it with other guards), or even completely eliding it, is acceptable.

This does require guards to be extremely cheap to evaluate; your optimized code is going to check a lot of them unless your guard motion + elision system is very good.