On Friday, June 27, 2014 11:09:11 PM UTC-4,
Steven D'Aprano wrote:
> Having said that, I think that the OP's question
> is probably misguided.
Thanks, Steven, for the input. It very well might be.
I'll give a little more information.
> He or she gives the impression of expecting PyPy
> or Nuitka to be a magic button that will speed up
> the user experience, like the Turbo button on
> old PCs. (Remember them?) It's not likely to be
> that easy.
I'm sure it does give just that impression. I'll
admit that if it *did* do something like that, I'd
be pleased, of course. But I expected it not to work
so well as that, or perhaps not work at all. Really,
I asked more out of curiosity, since these projects
keep staying out there but I rarely read about people
actually using them. They seem more like proof of
principle intellectual work, but I really know not of
what I speak, and so was trying to get more
understanding. I also thought it may be helpful in
creating a standalone executable (instead of using
the various ways to do that with Python, which I am
familiar with and have done successfully), and wanted
to see if there were any advantages to that (such as
a smaller file size).
> wxPython is a wrapper to a C GUI library, all the
> work is done in C, not Python,
There are some pure Python widgets in wxPython, such
as many or perhaps all within the AGW subdirectory,
which are some really nice contributions by Andrea
Gavana. And I believe it's a C++ library, not C.
> so moving to PyPy or Nuitka won't speed it up.
It may not; I really wasn't sure and thought I'd
give it a try and see what happened (if it wasn't
a major undertaking to give it a try).
> Additionally, in most GUI apps (although not all),
> the main bottleneck is usually not the programming
> language but the user. GUI apps tend to spend
> 95% of their time idling, waiting for the user. Its
> been a *long* time since the GUI framework itself
> has lagged behind the user's input, except
Although that is true, I have found that I have
managed to get wxPython apps to feel laggy in certain
parts, particularly on not-very-fast computers. I
can see this in starting up the program and some
other areas such as repainting damaged windows
rapidly. It's not a huge effect, but it does
influence the "look and feel" and I care about it.
> except in cases of memory exhaustion.
Maybe this is a key issue on one of the older
laptops I was testing on. The thing is, though,
there are still a lot of SLOW computers out there
in userland, sadly, and doing what one can to
mitigate the laggy UX by speeding up the program
seems like a virtuous goal.
> his or her application, the first thing to do is
> to identify what parts of it are slow, identify
> why they're slow, and concentrate on those parts.
That's underway, and helping. I just idly thought
about the state of compilers and JIT and such and