[Python-Dev] PEP 509: Add a private version to dict (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Wed Jan 20 13:15:21 EST 2016

The easiest version is to have global numbering (as opposed to local).

Anyway, I would strongly suggest getting some benchmarks done and showing performance benefits first, because you don't want PEPs to be final when you don't exactly know the details.

On Wed, Jan 20, 2016 at 7:02 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

On 2016-01-18 5:43 PM, Victor Stinner wrote:

Is someone opposed to this PEP 509? The main complain was the change on the public Python API, but the PEP doesn't change the Python API anymore. I'm not aware of any remaining issue on this PEP. Victor, I've been experimenting with the PEP to implement a per-opcode cache in ceval loop (I'll share my progress on that in a few days). This allows to significantly speedup LOADGLOBAL and LOADMETHOD opcodes, to the point, where they don't require any dict lookups at all. Some macro-benchmarks (such as chameleonv2) demonstrate impressive ~10% performance boost. I rely on your dict->maversion to implement cache invalidation. However, besides guarding against version change, I also want to guard against the dict being swapped for another dict, to avoid situations like this: def foo(): print(bar) exec(foo.code, {'bar': 1}, {}) exec(foo.code, {'bar': 2}, {}) What I propose is to add a pointer "maextra" (same 64bits), which will be set to NULL for most dict instances (instead of maversion). "maextra" can then point to a struct that has a globally unique dict ID (uint64), and a version tag (unit64). A macro like PyDictGETID and PyDictGETVERSION could then efficiently fetch the version/unique ID of the dict for guards. "maextra" would also make it easier for us to extend dicts in the future. Yury

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/fijall%40gmail.com

More information about the Python-Dev mailing list