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" <mar...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
