[Python-Dev] PEP 393 review
Guido van Rossum
guido at python.org
Fri Aug 26 16:56:05 CEST 2011
Also, please add the table (and the reasoning that led to it) to the PEP.
On Fri, Aug 26, 2011 at 7:55 AM, Guido van Rossum <guido at python.org> wrote:
> It would be nice if someone wrote a test to roughly verify these
> numbers, e.v. by allocating lots of strings of a certain size and
> measuring the process size before and after (being careful to adjust
> for the list or other data structure required to keep those objects
> alive).
>
> --Guido
>
> On Fri, Aug 26, 2011 at 3:29 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> 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
>>
>>
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
--
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev
mailing list