Speed

Hello, I have started programming with python,
and have been trying to pick a good cross-platform gui toolkit. I have settled on wxPython after trying pyGtk, and pondering python bindings for fox and qt. wxWindows actually works, and has a native look and feel. Nice. There is one thing though.

It takes significantly longer to start up than pyGtk,
and has a larger memory footprint. How can I get around this?

I thought importing only those parts of the wxwindows modules that I need to use would help, but I do not know how to do this. Any ideas?

Any thoughts on ways to speed up the load time for my programs?

Thank you,

Daniel

DanSV@aol.com wrote:

Hello, I have started programming with python, and have been trying
to pick a good cross-platform gui toolkit. I have settled on
wxPython after trying pyGtk, and pondering python bindings for fox
and qt. wxWindows actually works, and has a native look and feel.
Nice. There is one thing though.

It takes significantly longer to start up than pyGtk, and has a
larger memory footprint. How can I get around this?

I thought importing only those parts of the wxwindows modules that I
need to use would help, but I do not know how to do this. Any ideas?

Any thoughts on ways to speed up the load time for my programs?

There really isn't a good solution for this yet, other than custom building and leaving out lots of stuff in wxWindows and wxPython. I do have some ideas though that I'll be able to try out in the 2.5 timeframe.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hello, I have started programming with python,
and have been trying to pick a good cross-platform gui toolkit. I have settled on wxPython after trying pyGtk, and pondering python bindings for fox and qt. wxWindows actually works, and has a native look and feel. Nice.

I'm curious about the considerations you and others have
made in these decisions. I've discarded PyQT since it's
too expensive for me on Windows, and PyGtk since I was
sceptical of its maturity on Windows, but at least PyQt
and Qt has very loyal proponents who seem to think it's
much better than the competition. (Not trying to start any
flame war, just curious.)

It takes significantly longer to start up than pyGtk,
and has a larger memory footprint. How can I get around this?

I just have one ugly little piece of advice, which might
nevertheless be useful. Often, the problem is not the startup
delay itself, but the *percieved* startup delay, and maybe
most of all the lack of feedback. (Didn't it start? Why isn't
anything happening?)

Try to make something happen on the screen as soon as possible.
Trow up a splash screen or something like that as soon as
possible. Maybe you can even open the splash screen as a Tkinter
screen, so that it won't have to wait for the wx code? A
TkSimpleDialog or whatever they are called is fast.

With Jef Raskin's Canon Cat computer, you would start work
where you were the last time you used it. It saved a screen
dump as you turned it off, and next time you turned it on,
this screen dump was displayed before it even loaded the
application (I don't think it had an OS) and long before the
data file was loaded. People felt it was blinding fast. By
the time they remembered what they were doing, and started
typing, the loading was about done...

There's also this famous old story about a department store where
people complained that they had to wait so long by the elevators.
This was solved, not by making the elevators faster, but by putting
mirrors on the walls by the elevator doors. The complaints stopped.

···

At 18:15 2003-05-04 -0400, DanSV@aol.com wrote:

--
Magnus Lycka (It's really Lyckå), magnus@thinkware.se
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program

Not a bad idea for an interim solution. I wonder if instead of pulling
in "yet another gui framework" and hoping that they won't conflict (not
too mention bloating your installer), if simple WIN32 calls could be
made using like ctypes or Venster, both of which are pretty small:

  http://starship.python.net/crew/theller/ctypes.html
  http://venster.sourceforge.net/

Haven't tried it yet, but I suspect the end result would be extremely
lightweight...

···

On Monday 05 May 2003 04:22 pm, Magnus Lyckå wrote:

Try to make something happen on the screen as soon as possible.
Trow up a splash screen or something like that as soon as
possible. Maybe you can even open the splash screen as a Tkinter
screen, so that it won't have to wait for the wx code? A
TkSimpleDialog or whatever they are called is fast.

--
Chuck
http://ChuckEsterbrook.com

Robin Dunn wrote:
> DanSV@aol.com wrote: ...
>> It takes significantly longer to start up than pyGtk, and has a
>> larger memory footprint. How can I get around this?
>> I thought importing only those parts of the wxwindows modules that I
>> need to use would help, but I do not know how to do this. Any ideas?
> There really isn't a good solution for this yet, other than custom
> building and leaving out lots of stuff in wxWindows and wxPython. I
> do have some ideas though that I'll try out in the 2.5 timeframe.

I have an idea (which may be neither new nor correct).

The standard advice in wxPython (and similarly for other GUI toolkits)
is to use "from wxPython.wx import *". This of necessity adds almost
3000 symbols to the symbol table. In some of my attempts to learn
wxPython, this has frustrated me. If for no other reason, each dir()
returns a disgustingly long set of symbols. Even if I am not trying
to look at wx stuff, I have so many symbols that I am afraid to do a
dir(). I attempted to solve this, at least for the purposes of
learning wxPython, and this is what I wound up with:

I have a module (wxx.py), which simply imports wxPython.wx and
tries to classify each symbol into a "place it belongs".

One of the things I've noticed is that wxPython recapitulates each
symbol's prevenance in its name. I (strongly) suspect this has a
lot to do with the SWIG wrapping of the wxWindow code. Since one
of my goals was to enable simple translation from existing wxPython
code, here's what I came up with:

instead of:
  from wxPython.wx import *
use:
  from wxx import * # Or wxPython.wxx or whatever

Then in subsequent text:
For: Substitute:
   WXK_NUMPAD_NAME WXK_NUMPAD.NAME
   WXK_NAME WXK.NAME
   IDM_NAME IDM.NAME
   EVT_COMMAND_NAME EVT_COMMAND.NAME
   EVT_LIST_NAME EVT_LIST.NAME
   EVT_SCROLLWIN_NAME EVT_SCROLLWIN.NAME
   EVT_SCROLL_NAME EVT_SCROLL.NAME
   EVT_NAME EVT.NAME
   wxALL_CAPS_NAME WX.ALL_CAPS_NAME
   wxOtherName wx.OtherName
   cvar Misc.cvar
   NewId Misc.NewId
   localedir Misc.localedir
   RegisterId Misc.RegisterId

We will have code that copies in 11 symbols, rather than 2746 symbols.
The core of the problem that I see here is that SWIG uses a flat
namespace as the model of providing symbols, rather than allowing
structured names. Since Python is particularly good at namespaces,
Python is particularly penalized by this mapping.

The code for wxx.py is rather simple and boring if you agree about
the causes, and it is irrelevant if you don't find my arguments about
importing many symbols persuasive. If this is the way to go, lots
of wxPython modules should be recoded to use this scheme.

Very roughly, the code of wxx.py looks like:

import wxPython.wx
<define a class Identifier(prefix)>
_prefixed = [(n, Identifier(n[:-1])) for n in ('IDM_ WXK_NUMPAD_ WXK_ '
      'EVT_LIST_ EVT_COMMAND_ EVT_SCROLLWIN_ EVT_SCROLL_ EVT_').split()]

IDM, WXK_NUMPAD, WXK, EVT_LIST, EVT_COMMAND, EVT_SCROLLWIN, \
  \ EVT_SCROLL, EVT_ = [obj for name, obj in _prefixed]

WX = Identifier('wx')
wx = Identifier('wx')
Misc = Identifier('')

wxPwx = wxPython.wx
for name in dir(wxPwx):
     for prefix, obj in _prefixed:
        if name.startswith(prefix):
            setattr(obj, name[len(prefix):], getattr(wxPwx, name))
            break
     else:
        if name.startswith('wx'):
            if name[2:] == name[2:].upper():
                setattr(WX, name[2:], getattr(wxPwx, name))
            else:
                setattr(wx, name[2:], getattr(wxPwx, name))
        else:
            setattr(Misc, name, getattr(wxPwx, name))

Reactions? Does this sound useful or a waste? The idea came from
seeing a many-module wxPython app where every module begins with
"from wxPython.wx import *".

-Scott David Daniels
Scott.Daniels@Acm.Org

Not only you. There is an ongoing effort to change the
style from

from wxPython.wx import * ... f = wxFrame(...

to

import wx ... f = wx.Frame(...

Patrick O'Brien have done some work on this. Look in the mailing
list archives for March. See
http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?11:sss:17092:200303:iocbemcaodfcmahejiin#b
and
http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?11:sss:16895:200303:gfojapeddmndhmijgiia#b
and
http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?11:sss:17082:200303:lnlhdcbnkfbgbgmjjjcp#b
etc

···

At 23:01 2003-05-15 -0700, Scott David Daniels wrote:

The standard advice in wxPython (and similarly for other GUI toolkits)
is to use "from wxPython.wx import *". This of necessity adds almost
3000 symbols to the symbol table. In some of my attempts to learn
wxPython, this has frustrated me.

--
Magnus Lycka (It's really Lyck&aring;), magnus@thinkware.se
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program