On Thu, Jan 21, 2010 at 12:25:59PM +0000, Antoine Pitrou wrote: > > We seek guidance from the community on > > an acceptable level of increased memory usage. > > I think a 10-20% increase would be acceptable. > I'm just a user of the core interpreter but the bottleneck in using python in my environment has almost always been memory usage and almost never speed of execution. Note, though, that we run multiple python apps at a time so anything that's shared between interpreters is less costly than anything that must be unique.
Still, any growth in memory usage is painful since that's already the limiting resource. > > 32-bit; gcc 4.0.3 > > > > +-------------+---------------+---------------+----------------------+ | > > Binary size | CPython 2.6.4 | CPython 3.1.1 | Unladen Swallow r988 | > > +=============+===============+===============+======================+ | > > Release | 3.8M | 4.0M | 74M | > > +-------------+---------------+---------------+----------------------+ | > > This is positively humongous. Is there any way to shrink these numbers > dramatically (I'm talking about the release builds)? Large executables or > libraries may make people anxious about the interpreter's memory > efficiency; and they will be a nuisance in many situations (think making > standalone app bundles using py2exe or py2app). > Binary size has an impact on linux distributions (and people who make embedded systems from those distributions). This kind of growth would push the interpreter out of the livecds that we make and prevent shipping other useful software on our DVDs and other media. Somebody suggested building two interpeters in another part of this thread (jit-python and "normal" python). That has both pros and cons in situations like this: 1) For some programs that we want to use the jit-python binary if available, we'd need to implement some method of detecting its presence and using it if present. 2) We'd need to specify that both jit-python and python are able to run this program successfully. 3) If the compiled modules (byte code or C compiled) are incompatible between the two interpreters that will make us cry. (we're already shipping two versions of things for python2.x and python3.x, also shipping a version for jit-python would be... suboptimal.) -Toshio
pgpOFpN8U0kT3.pgp
Description: PGP signature
_______________________________________________ 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
