Why is the __dict__ of instances so much smaller in size in Python 3?

Question

In Python, dictionaries created for the instances of a class are tiny compared to the dictionaries created containing the same attributes of that class:

impo         


        

Answer 1

In short:

Instance __dict__'s are implemented differently than the 'normal' dictionaries created with dict or {}. The dictionaries of an instance share the keys and hashes and the keep a separate array for the parts that differ: the values. sys.getsizeof only counts those values when calculating the size for the instance dict.

A bit more:

Dictionaries in CPython are, as of Python 3.3, implemented in one of two forms:

• Combined dictionary: All values of the dictionary are stored alongside the key and hash for each entry. (me_value member of the PyDictKeyEntry struct). As far as I know, this form is used for dictionaries created with dict, {} and the module namespace.
• Split table: The values are stored separately in an array, while the keys and hashes are shared (Values stored in ma_values of PyDictObject)

Instance dictionaries are always implemented in a split-table form (a Key-Sharing Dictionary) which allows instances of a given class to share the keys (and hashes) for their __dict__ and only differ in the corresponding values.

This is all described in PEP 412 -- Key-Sharing Dictionary. The implementation for the split dictionary landed in Python 3.3 so, previous versions of the 3 family as well as Python 2.x don't have this implementation.

The implementation of __sizeof__ for dictionaries takes this fact into account and only considers the size that corresponds to the values array when calculating the size for a split dictionary.

It's thankfully, self-explanatory:

Py_ssize_t size, res;

size = DK_SIZE(mp->ma_keys);
res = _PyObject_SIZE(Py_TYPE(mp));
if (mp->ma_values)                    /*Add the values to the result*/
    res += size * sizeof(PyObject*);
/* If the dictionary is split, the keys portion is accounted-for
   in the type object. */
if (mp->ma_keys->dk_refcnt == 1)     /* Add keys/hashes size to res */
    res += sizeof(PyDictKeysObject) + (size-1) * sizeof(PyDictKeyEntry);
return res;

As far as I know, split-table dictionaries are created only for the namespace of instances, using dict() or {} (as also described in the PEP) always results in a combined dictionary that doesn't have these benefits.

---

As an aside, since it's fun, we can always break this optimization. There's two current ways I've currently found, a silly way or by a more sensible scenario:

1. Being silly:

   >>> f = Foo(20, 30)
   >>> getsizeof(vars(f))
   96
   >>> vars(f).update({1:1})  # add a non-string key
   >>> getsizeof(vars(f))
   288
   

   Split tables only support string keys, adding a non-string key (which really makes zero sense) breaks this rule and CPython turns the split table into a combined one loosing all memory gains.

2. A scenario that might happen:

   >>> f1, f2 = Foo(20, 30), Foo(30, 40)
   >>> for i, j in enumerate([f1, f2]):
   ...    setattr(j, 'i'+str(i), i)
   ...    print(getsizeof(vars(j)))
   96
   288
   

   Different keys being inserted in the instances of a class will eventually lead to the split table getting combined. This doesn't apply only to the instances already created; all consequent instances created from the class will be have a combined dictionary instead of a split one.

   # after running previous snippet
   >>> getsizeof(vars(Foo(100, 200)))
   288
   

of course, there's no good reason, other than for fun, for doing this on purpose.

---

If anyone is wondering, Python 3.6's dictionary implementation doesn't change this fact. The two aforementioned forms of dictionaries while still available are just further compacted (the implementation of dict.__sizeof__ also changed, so some differences should come up in values returned from getsizeof.)