This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients lemburg, orivej, pitrou
Date 2008-01-26.23:27:33
SpamBayes Score 0.00177163
Marked as misclassified No
Message-id <1201390055.27.0.353725007691.issue1943@psf.upfronthosting.co.za>
In-reply-to
Content
The Unicode object was designed not to be a PyVarObject (in contrast to
the string object), so I'm not sure what you would want to break that
design in return for a mere 10% speedup.

Note that turning the objects into PyVarObjects removes the ability to
extend the type at C level. It also introduces lots of problems if you
want to resize a Unicode object, due to the fact that the memory address
of the whole PyUnicodeObject can change. Resizing is done quite often in
codecs.

Regarding your second point: Unicode objects already use a free list and
even keep the allocated Py_UNICODE buffer allocated (if it's not too
large). Furthermore, the allocation is handled by pymalloc, so you only
rarely need to go to the system malloc() to allocate more space.

Tuning the KEEPALIVE_SIZE_LIMIT will likely have similar effects w/r to
speedup.
History
Date User Action Args
2008-01-26 23:27:35lemburgsetspambayes_score: 0.00177163 -> 0.00177163
recipients: + lemburg, pitrou, orivej
2008-01-26 23:27:35lemburgsetspambayes_score: 0.00177163 -> 0.00177163
messageid: <1201390055.27.0.353725007691.issue1943@psf.upfronthosting.co.za>
2008-01-26 23:27:34lemburglinkissue1943 messages
2008-01-26 23:27:33lemburgcreate