Speed up "create class"

[gvanrossum]

This operation seems rather baroque. We should profile it and speed it up.

(See also #32.)

[methane]

Previous attempt: https://bugs.python.org/issue32346

[markshannon]

One way to speed up class creation might be to not populate or use the "slots" at all and rely on the class's dict.
It would probably make attribute lookup faster as well and we could delete a whole lot of code in typeobject.c

Why slots aren't efficient

The global (now per interpreter?) method lookup cache works well for normal attribute lookups. There is no reason why it can't work for special names like __iter__ and __next__.
For operations (+, -, [], next(), etc) we will want to specialize for common builtin types (int, list, etc), and remove the lookup overhead altogether.
For operations on types that are "hot" but not a common builtin type, e.g. numpy arrays, we can either use the PEP 659 cache, or a global cache to speed up look up.

For binary operations we are looking into a (theoretical) large and sparse 3D array [type(left), type(right), operation]
Slots are effectively a physically sparse 2D array [type(left), operation]. So using slots is doubly inefficient as we not only need to lookup in a physically sparse data structure, we need to do double dispatching.
Using a physically dense custom data structure, like the method cache, but for pairs of types would be faster.

[gvanrossum]

Unfortunately __slots__ also have semantic meaning, some people use them to explicitly disallow other attribute names (to prevent typos when setting attributes).

AFAIK the "method" lookup cache actually caches all class attributes including the descriptors used by slots.

[JelleZijlstra]

I think Mark is referring to the C-level slots (tp_hash and that sort of thing). Changing how those behave wouldn't necessarily affect the Python-level __slots__. What Mark proposes is certainly a huge change though, and I wouldn't be surprised if it has tricky backwards-compatibility implications.