[Python-Dev] Removing Non-Unicode Support?

"Martin v. Löwis" martin at v.loewis.de
Mon Feb 20 23:38:27 CET 2006


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


More information about the Python-Dev mailing list