steering-council
steering-council copied to clipboard
python
PEP 669 -- Low Impact Monitoring for CPython
Please consider PEP 669 -- Low Impact Monitoring for CPython https://peps.python.org/pep-0669/
Discussed here: https://discuss.python.org/t/pep-669-low-impact-monitoring-for-cpython/13018 This PEP was also announced on Python dev, but there was no response there.
The PEP incorporates feedback from the potential users.
Even if no one uses this PEP, it provides a mechanism to speed up CPython by ~1% by eliminating the runtime overhead of supporting sys.setprofile() and sys.settracing().
I expect that it will be used, though. Slipcover already uses a similar, but somewhat ad-hoc, approach to perform coverage. Running tests with Slipcover coverage on 3.11 is faster than running tests with no coverage on 3.10. PEP 669 should allow coverage.py to use a similar approach, without the hacks, and even better performance.
Given that debuggers using PEP 669 will be much faster than using PEP 523 or sys.settracing(), I expect debuggers to adopt it as well.
The Steering Council accepts PEP 669 (Low Impact Monitoring for CPython).
We'd like to point out that, as with any PEP, if the initial implementation requires design changes, they need to be re-approved and noted in the PEP (see PEP 1).
Please just ping a SC member on the pull request if/when you change the PEP.
To be clear, we expect that all claims in the PEP will hold, and that the PEP will mention all known cases where the implementation degrades performance.
If the changes are unacceptable, the SC may still reject the PEP and ask for reverting the change. (You could say the PEP is "provisionally accepted, pending the implementation" -- except it's how PEP acceptance works in general. In this case, the SC does still have some reservations, but a successful implementation would be the best way to resolve them.)
— Petr, on behalf of the SC