[Python-Dev] PEP 393 review

"Martin v. Löwis" martin at v.loewis.de
Fri Aug 26 12:29:29 CEST 2011


> But strings are allocated via PyObject_Malloc(), i.e. the custom
> arena-based allocator -- isn't its overhead (for small objects) less
> than 2 pointers per block?

Ah, right, I missed that. Indeed, those have no header, and the only
overhead is the padding to a multiple of 8.

That shifts the picture; I hope the table below is correct,
assuming ASCII strings.
3.2: 7 pointers (adds 4 bytes padding on 32-bit systems)
393: 10 pointers

string | 32-bit pointer | 32-bit pointer | 64-bit pointer
size   | 16-bit wchar_t | 32-bit wchar_t | 32-bit wchar_t
       | 3.2     |  393 | 3.2    |  393  | 3.2    |  393  |
-----------------------------------------------------------
1      | 40      | 48   | 40     |  48   | 64     | 88    |
2      | 40      | 48   | 48     |  48   | 72     | 88    |
3      | 40      | 48   | 48     |  48   | 72     | 88    |
4      | 48      | 48   | 56     |  48   | 80     | 88    |
5      | 48      | 48   | 56     |  48   | 80     | 88    |
6      | 48      | 48   | 64     |  48   | 88     | 88    |
7      | 48      | 48   | 64     |  48   | 88     | 88    |
8      | 56      | 56   | 72     |  56   | 96     | 86    |

So 1-byte strings increase in size; very short strings increase
on 16-bit-wchar_t systems and 64-bit systems. Short strings
keep there size, and long strings save.

Regards,
Martin




More information about the Python-Dev mailing list