[Dev] static linking Python, wxWindows and wxPython
Morgen Sagen
morgen at osafoundation.org
Fri May 23 10:51:26 PDT 2003
Robin,
Thanks for looking into this. I have also been told that the slow OSX startup
times might be improved by something called "prebinding", where the locations
of all external required symbols are cached. I have noticed the first time
you launch Chandler after installing it, it takes (yikes) 22 seconds on my Ti
Powerbook G4 to get the splash screen. Then after a reboot (to make sure none
of the files are cached) the splash screen comes up in 15 seconds. So
prebinding alone (a process which happens automatically on OSX after the first
time you launch an app) knocks off 7 seconds. Subsequent launch times without
a reboot are only around 8 seconds, presumably because of caching. The amount
of time taken up compiling all of Chandler's .py files to .pyo files is
negligible (I compared launch times with the .pyo files in place and without).
Apparently prebinding takes place when you install an application via an
installer package, so I will be looking into putting one together. I will
also try your instructions for linking in wxWindows+extensions into the python
interpreter too and see what improvements we get (I feel your pain -- a build
takes about an hour on my Powerbook).
~morgen
--On Thursday, May 22, 2003 9:45 PM -0700 Robin Dunn <robin at alldunn.com> wrote:
> Last week on #chandler there was a discussion about trying to reduce the
> startup time of wxPython apps such as Chandler on OS X and I tossed out the
> idea of linking wxWindows and the wxPython extension modules staticly into
> the Python interpreter. I've spent a bit of time on it yesterday and today
> and thought I would describe what I have so far before the long weekend
> makes me forget everything <wink>
>
> I have a script that I'll put in wxPython's distrib dir that essentially
> uses wxPython's setup.py to gather info about all the extension modules and
> their source files and then generates a Setup.local file for the Python
> build. (The Setup* files are the "old way" of building extensions for
> Python, but they still work and are, AFAIK the only way to automate static
> linking of extensions.)
>
> I still need to do a similar script that will install all the packages and
> their .py files after Python is built, since the script above is only for
> the extension modules. I'll hopfully get that part done tomorrow.
>
> Morgen, if you want me to also fiddle with the hardhat scripts I can do
> that, but not until next week. However I usually end up stumbling around in
> them so it may be quicker if you update them. Essentially these changes
> will need to be done:
>
> 1. Build wxWindows (but not wxPython) *before* Python.
>
> 2. Use the --enable-static flag for wxWindows' configure.
>
> 3. From the wxpython/wxPython directory run distrib/make_static_setup.py,
> redirecting the output of that script to python/Modules/Setup.local. You
> should add whatever command line parameters that you normally use on
> wxPython's setup.py to this script's command line. (BTW, this step can be
> done with whatever version of Python is running hardhat, it doesn't have to
> be Chandler's Python, so there is no chicken and egg problem.)
>
> 4. Configure and build Python like normal. It will automatically find the
> Setup.local and use the info in it to update its Makefile.
>
> 5. The final step will be to run the script that I still need to write that
> will install the wxPython package (*.py* files only) in site-packages. This
> one will need to be run with the Python built above.
>
> I've been experimenting with it on Linux (because the compiler there is
> about 10 times as fast as doing it on my Mac) but I expect that it should
> work fine on OS X too. I'll try doing it on OSX tomorrow if I have time
> after finishing the other script and before heading off for the weekend. On
> Linux I did notice a decrease in startup time, but since it wasn't too bad
> to begin with it wasn't a huge difference. Starting the wxPython demo (from
> pressing Enter until the splash screen pops up) went from something around 2
> or 2.5 seconds to less than 1 second.
>
> BTW, if we want to do the same thing for the Windows platform then that will
> take hacking the Python project file and the above technique won't help.
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev
More information about the Dev
mailing list