[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