Replace non-performance-critical opcodes by call to methods of an internal object. #202
Replies: 6 comments
-
Seems worth exploring. |
Beta Was this translation helpful? Give feedback.
-
Other candidates for lowering are:
|
Beta Was this translation helpful? Give feedback.
-
If we add a
|
Beta Was this translation helpful? Give feedback.
-
How cheap is raising an exception? 99.9% of LOAD_CLASSDEREF will raise NameError, which means a NameError object is created and immediately discarded. |
Beta Was this translation helpful? Give feedback.
-
Raising an exception is expensive. Relative to the simple lookup, very expensive. So let's not do that.
and
|
Beta Was this translation helpful? Give feedback.
-
There are a number of opcodes which are not performance critical and which seem to exist for the sole purpose of invoking a function or loading a non-picklable constant to the stack (which could be returned from a function). Examples:
LOAD_ASSERTION_ERROR, IMPORT_NAME, IMPORT_FROM, PRINT_EXPR, PREP_RERAISE_STAR.
Perhaps we could create a simple (picklable) object that has these functions as its methods, so that the compiler can load this object to the stack and invoke the methods via a series of generic opcodes. This object should ideally not be accessible from python, it should be stateless, it certainly should not be subclassable and the methods should be immutable.
This is an alternative to an idea that came up previously, to load AssertionError via a new LOAD_COMMON_CONST opcode that fetches it from an internal consts array. That approach could be good for performance critical consts, but for the slow ones we don’t actually need an opcode at all.
Beta Was this translation helpful? Give feedback.
All reactions