On Sat, Jun 28, 2014 at 2:14 PM, Michael Torrie <torr...@gmail.com> wrote: > On 06/27/2014 09:44 PM, CM wrote: >>> 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. > > I highly doubt this lagginess has anything to do with Python, honestly. > If you're seeing slowdowns in the areas you state, you'll probably > experience the same issues in the equivalent C++ version. All drawing > is done by the underlying binary library. > > I've made GUIs in GTK and Qt with Python and never had any that was > appreciably slower than C or C++ apps.
Agreed, and there's a fairly easy way to test it (at least, under Linux): just look in 'top' and see if a significant proportion of the time is spent in a process called Xorg rather than your python process. The last time I had a program that could actually saturate a thread with GUI API calls, it generally ended up split somewhere between 25% and 75% across my process and Xorg. (Best I could do just now, in testing, was to hold PgUp/PgDn in an unoptimized program that repainted the screen immediately whenever it needed to. According to top, I was using 52% of a core in Xorg, and about 16% of a core in my code. With a slower computer, that would work out to 75% Xorg and 25% high level code.) At that point, changing language won't affect performance one iota, and certainly changing Python interpreter won't do anything for you. The way to improve performance is to cut out some of the drawing calls. (The saturation problem came because the code was naively trying to draw a whole lot of stuff that was hidden behind a scroll viewport. Adding a quick check "is this sorta close to the screen" gave me all the improvement I needed.) The only other time I've been waiting for X display was when I was mobile, on a 3G connection, and using X11 forwarding on an SSH link back to my home LAN. For some reason, displaying a remote desktop view of a VM takes quite a while when every pixel has to be sent over 3G... but, again, no Python code performance involved :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
