Using emacs' unexec to speed Python startup (was Re: [Python-Dev] Startup time)

Daniel Berlin dberlin@dberlin.org
Mon, 19 May 2003 23:04:35 -0400


On Monday, May 19, 2003, at 08:06  AM, Jeff Epler wrote:

> O Sun, May 18, 2003 at 11:28:08PM -0400, Barry Warsaw wrote:
>> Since it looks like you implemented the meat of it as a module, I
>> wonder if it couldn't be cleaned up (with the interrupt reset either
>> pulled in the extension or exposed to Python) and added to Python 2.3?
>
> First off, I sure doubt that this feature could be truly made
> "non-experimental" before 2.3 is released.  There was one "strange 
> bug" so
> far (the signal thing), though that was quickly solved (with another
> change to the core Python source code).
>
> Secondly, forcing all allocations to come from the heap instead of 
> mmap'd
> space may hurt performance.
>
> Thirdly, the files implementing unexec itself, which come from fsf 
> emacs,
> are covered by the GNU GPL, which I think makes them unsuitable for
> compiling into Python. (There's something called "dynodump" in Emacs 
> that
> appears to apply to ELF binaries which bears this license:
>  * This source code is a product of Sun Microsystems, Inc. and is 
> provided
>  * for unrestricted use provided that this legend is included on all 
> tape
>  * media and as a part of the software program in whole or part.  Users
>  * may copy or modify this source code without charge, but are not 
> authorized
>  * to license or distribute it to anyone else except as part of a 
> product or
>  * program developed by the user.
> I wish I understood what "except as part of a product or program 
> developed
> by the user" meant--does that mean that Alice can't download Python
> then give it to Bob if it includes dynodump?  After all, Alice didn't
> develop it, she simply downloaded it.  The other dumpers in xemacs
> seem to be GPL, and I think that the "portable undump" mentioned by
> another poster is a placeholder for a project that isn't written yet:
> http://www.xemacs.org/Architecting-XEmacs/unexec.html)
It was written and is on by default  since 21.2 came out, the website 
is out of date.

See http://www.xemacs.org/Releases/Public-21.2/projects/pdump.html

It's probably too xemacs specific, however.

The file you want is dumper.c.

>
> Fourthly, we'd have to duplicate whatever machinery chooses the correct
> unexec implementation for the platform you're running on---there are 
> lots to
> choose from:

Only if you do undumping the same way. The portable dumper way was to 
not make an executable, instead putting it in a seperate file, and 
storing it in a neutral format that was architected to make loading 
fast.
It's still faster than loading byte-compiled files, since nothing needs 
to be executed as we are just recreating the in-memory representation.

> 	unexaix.c     unexconvex.c  unexenix.c     unexnext.c    unexw32.c
> 	unexalpha.c   unexec.c      unexhp9k800.c  unexsni.c
> 	unexapollo.c  unexelf.c     unexmips.c     unexsunos4.c
> (Of course, it's well known that only elf and win32 matter in these 
> modern
> times)
>
> I'd be excited to see "my work" in Python, though the fact of the 
> matter
> is that I just tried this out because I was bored on a Sunday 
> afternoon.
>
> Jeff
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev