The opcode module contains several collections: `cmp_op` `hasconst` `hasname` `hasjrel` ... which are only used for `in` checks. At the same time, they are stored as `list`s and `cmp_op` as tuple. Both these types are not optimal for `__contains__` checks. Maybe it is worth at least to convert them to `frozenset` type after they are filled?
This list are short. I don't think there is a large benefit of this change. But there is a small risk of breaking a third party code (for example hasjrel+hasjabs).
Small risk of breaking is a fair point (maybe some FutureWarning with new __getattr__ PEP 562?). I've checked several packages: --- vstinner/bytecode:: uses: @staticmethod def _has_jump(opcode): return (opcode in _opcode.hasjrel or opcode in _opcode.hasjabs) --- maynard:: defines them as sets and does not rely on opcode module. all_jumps = absolute_jumps | relative_jumps --- numba:: converts them to frozensets: JREL_OPS = frozenset(dis.hasjrel) JABS_OPS = frozenset(dis.hasjabs) JUMP_OPS = JREL_OPS
JABS_OPS --- codetransfromer:: uses: absjmp = opcode in hasjabs reljmp = opcode in hasjrel --- anotherassembler.py:: uses elif opcode in hasjrel or opcode in hasjabs: --- byteplay:: converts them to set: hasjrel = set(Opcode(x) for x in opcode.hasjrel) hasjabs = set(Opcode(x) for x in opcode.hasjabs) hasjump = hasjrel.union(hasjabs) --- byterun:: uses: elif byteCode in dis.hasjrel: arg = f.f_lasti + intArg elif byteCode in dis.hasjabs: arg = intArg In fact, all of the above indicated does not mean anything, but I have not found cases of hasjrel+hasjabs. Despite the fact that they are small, on average, with sets I gain 5-6x speed-up.
