Message 415268 - Python tracker (original) (raw)

Thanks for the extended example.

I think in order for this example to answer the question I asked, a few more assumptions should be made explicit:

1. Either spam_var and/or eggs_var are frequently re-bound to new values in a hot code path somewhere. (Given the observations above about module-level code, we should assume for a relevant example this takes place in a function that uses global spam_var or global eggs_var to allow such rebinding.)

2. But spam_var and eggs_var are not read in any hot code path anywhere, because if they were, then the adaptive interpreter would be just as likely to decide to watch them as it is to watch EGGS_CONST, in which case any benefit of per-key watching in this example disappears. (Keep in mind that with possibly multiple watchers around, "unwatching" anything on the dispatch side is never an option, so we can't say that the adaptive interpreter would decide to unwatch the frequently-re-bound keys after it observes them being re-bound. It can always "unwatch" them in the sense of no longer being interested in them in its callback, though.)

It is certainly possible that this case could occur, where some module contains both a frequently-read-but-not-written global and also a global that is re-bound using global keyword in a hot path, but rarely read. But it doesn't seem warranted to pre-emptively add a lot of complexity to the API in order to marginally improve the performance of this quite specific case, unsupported by any benchmark or sample workload demonstrating it.

This might not be necessary for us right now

I think it's worth keeping in mind that PyDict_WatchKey API can always be added later without disturbing or changing semantics of the PyDict_Watch API added here.