M.-A. Lemburg wrote:
Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them.
Well, the cost of Unicode support is not so much in the algorithmic part, but in the tables that come along with it. AFAICT, everything but unicodectype is optional; that is 5KiB of code and 20KiB of data on x86. Actually, the size of the code *does* matter, at a second glance. Here are the largest object files in the Python code base on my system (not counting dynamic modules): text data bss dec hex filename 4845 19968 0 24813 60ed Objects/unicodectype.o 22633 2432 352 25417 6349 Objects/listobject.o 29259 1412 152 30823 7867 Objects/classobject.o 20696 11488 4 32188 7dbc Python/bltinmodule.o 33579 740 0 34319 860f Objects/longobject.o 34119 16 288 34423 8677 Python/ceval.o 35179 2796 0 37975 9457 Modules/_sre.o 26539 15820 416 42775 a717 Modules/posixmodule.o 35283 8800 1056 45139 b053 Objects/stringobject.o 50360 0 28 50388 c4d4 Python/compile.o 68455 4624 440 73519 11f2f Objects/typeobject.o 69993 9316 1196 80505 13a79 Objects/unicodeobject.o So it appears that dropping Unicode support can indeed provide some savings. For reference, we also have an option to drop complex numbers: 9654 692 4 10350 286e Objects/complexobject.o Regards, Martin