snappiness of wxPython apps

wxPython Users
1

I am one of a large number of slow computer owners. With 1.7 GhZ and 1 GB or RAM on Windows XP, running my 50% fragmented laptop while Firefox 17.0.1 has a few pages/tabs open (and up to 600,000 KB of memory eaten), and a few other applications are open, can cause the computer to go into molasses mode, where windows switching becomes painfully slow.

In testing out a wxPython application, I just found that after it was sitting unused-by-me and sort of running in the background while I used other programs, like Firefox, and then I switched to it, the main frame was responsive but then when I did a user action that caused a wxDialog to be launched, it took about 20 seconds for the dialog to appear. Yuck. I then used and closed that dialog, did the same type of action again, and now the dialog popped up almost instantly. (I should note that I am launching the whole app via Boa Constructor, an IDE).

I think this super-slow vs. fast dialog appearance discrepancy may be related to the “warm boot” of applications, in that when you close a program down Windows doesn’t really vacate the RAM of that program but sort of keeps it handy in case you need it again soon, but if you wait too long that RAM has to get used for something else.

So, question #1: is that thinking right? Do the instructions for how to make a dialog “hang around” when recently used and therefore dialogs launch much more quickly, but the instructions “fade away” if you haven’t launched a dialog in a few hours and so have to be loaded from disk again?

Question #2: Is there anything I could do about this to prevent it? I know the real answer is that my computer is to blame, but I also know that the reality is that there are still a lot of people who have old/slow computers (and sometimes far worse than mine, since, AFAIK, I don’t have much or any malware). If there is something that can be done to increase “snappiness”, it makes a huge difference, in my case, to usability of the application.

I haven’t tested this issue out on a py2exe’d version of my app, but will.

(And yes, I should get a better computer, and will…but in a way, this one has some value as a good test case for older computers).

Thanks,
Che

2

If you only have 1GB of RAM, several other applications open and an
IDE then most of your, not latest used, applications memory
allocations are swapped to hard disk - when you swap the the
application that has been in background and try to do just about
anything the RAM that it was using has to be reconstructed from the
hard disk, and to make the space for it a lot of that from the
application that was running last has to be swapped out to disk
first. If your hard disk is fragmented and you don’t have a
permanently allocated swap space it also has to find the spare bits
of disk before doing that. Hence the very slow response - once you
are running from RAM you are fine.
To speed things up - close other Applications, De-fragment Disk,
Allocate at least the recommended swap file size as a permanent swap
file, don’t us compressed disk , all
the usual tips. Keep in mind that support for XP ends next month.
Hope that helps.
Gadget/Steve

···

On 26/03/14 21:07, C M wrote:

              I am one of a large number of slow computer

owners. With 1.7 GhZ and 1 GB or RAM on Windows XP,
running my 50% fragmented laptop while Firefox 17.0.1
has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open,
can cause the computer to go into molasses mode, where
windows switching becomes painfully slow.

            In testing out a wxPython application, I just found that

after it was sitting unused-by-me and sort of running in
the background while I used other programs, like
Firefox, and then I switched to it, the main frame was
responsive but then when I did a user action that caused
a wxDialog to be launched, it took about 20 seconds
for the dialog to appear. Yuck. I then used and closed
that dialog, did the same type of action again, and now
the dialog popped up almost instantly. (I should note
that I am launching the whole app via Boa Constructor,
an IDE).

          I think this super-slow vs. fast dialog appearance

discrepancy may be related to the “warm boot” of
applications, in that when you close a program down
Windows doesn’t really vacate the RAM of that program
but sort of keeps it handy in case you need it again soon,
but if you wait too long that RAM has to get used for
something else.

        So, question #1:  is that thinking right?  Do the

instructions for how to make a dialog “hang around” when
recently used and therefore dialogs launch much more
quickly, but the instructions “fade away” if you haven’t
launched a dialog in a few hours and so have to be loaded
from disk again?

      Question #2:  Is there anything I could do about this to

prevent it? I know the real answer is that my computer is to
blame, but I also know that the reality is that there are
still a lot of people who have old/slow computers (and
sometimes far worse than mine, since, AFAIK, I don’t have much
or any malware). If there is something that can be done to
increase “snappiness”, it makes a huge difference, in my case,
to usability of the application.

      I haven't tested this issue out on a py2exe'd version of my

app, but will.

    (And yes, I should get a better computer, and will...but in a

way, this one has some value as a good test case for older
computers).

      Thanks,

      Che

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to wxpython-users+unsubscribe@googlegroups.com.

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

especially for swap disk

3

I seem to recall that on machines with those specs, adding RAM made a HUGE difference in the situation you describe, exactly because then the app you are switching to is less likely to have been swapped to the hard drive from RAM, as Gadget/Steve said.

This has nothing to do with wxPython, and py2exe probably won’t help just a ton. It’s an OS issue, not an application-specific issue.

David

···

On Wed, Mar 26, 2014 at 4:27 PM, Steve Barnes gadgetsteve@live.co.uk wrote:

On 26/03/14 21:07, C M wrote:

              I am one of a large number of slow computer

owners. With 1.7 GhZ and 1 GB or RAM on Windows XP,
running my 50% fragmented laptop while Firefox 17.0.1
has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open,
can cause the computer to go into molasses mode, where
windows switching becomes painfully slow.

            In testing out a wxPython application, I just found that

after it was sitting unused-by-me and sort of running in
the background while I used other programs, like
Firefox, and then I switched to it, the main frame was
responsive but then when I did a user action that caused
a wxDialog to be launched, it took about 20 seconds
for the dialog to appear. Yuck. I then used and closed
that dialog, did the same type of action again, and now
the dialog popped up almost instantly. (I should note
that I am launching the whole app via Boa Constructor,
an IDE).

          I think this super-slow vs. fast dialog appearance

discrepancy may be related to the “warm boot” of
applications, in that when you close a program down
Windows doesn’t really vacate the RAM of that program
but sort of keeps it handy in case you need it again soon,
but if you wait too long that RAM has to get used for
something else.

        So, question #1:  is that thinking right?  Do the

instructions for how to make a dialog “hang around” when
recently used and therefore dialogs launch much more
quickly, but the instructions “fade away” if you haven’t
launched a dialog in a few hours and so have to be loaded
from disk again?

      Question #2:  Is there anything I could do about this to

prevent it? I know the real answer is that my computer is to
blame, but I also know that the reality is that there are
still a lot of people who have old/slow computers (and
sometimes far worse than mine, since, AFAIK, I don’t have much
or any malware). If there is something that can be done to
increase “snappiness”, it makes a huge difference, in my case,
to usability of the application.

      I haven't tested this issue out on a py2exe'd version of my

app, but will.

    (And yes, I should get a better computer, and will...but in a

way, this one has some value as a good test case for older
computers).

      Thanks,

      Che

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to wxpython-users+unsubscribe@googlegroups.com.

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

If you only have 1GB of RAM, several other applications open and an

IDE then most of your, not latest used, applications memory
allocations are swapped to hard disk - when you swap the the
application that has been in background and try to do just about
anything the RAM that it was using has to be reconstructed from the
hard disk, and to make the space for it a lot of that from the
application that was running last has to be swapped out to disk
first. If your hard disk is fragmented and you don’t have a
permanently allocated swap space it also has to find the spare bits
of disk before doing that. Hence the very slow response - once you
are running from RAM you are fine.

To speed things up - close other Applications, De-fragment Disk,

Allocate at least the recommended swap file size as a permanent swap
file, don’t us compressed disk especially for swap disk , all
the usual tips. Keep in mind that support for XP ends next month.

Hope that helps.



Gadget/Steve

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

4

You could try turning RAM paging off, this can lead to really annoying and unstable behavior if/when your RAM fills up to the brim. Basically if you have paging off and fill up your physical RAM, things start to fail to open, which can lead to a crash/locked system.

Right-click on My Computer, click properties, click Advanced System Settings, click the Advanced tab then click Settings under the Performance section, click the Advanced tab again (in the Performance options that opened up), then finally click Change under ‘Virtual memory’.

I’ve got 8GB of RAM and still need paging :stuck_out_tongue:

RAM is addictive.

···

On Wednesday, March 26, 2014 2:07:59 PM UTC-7, Che M wrote:

I am one of a large number of slow computer owners. With 1.7 GhZ and 1 GB or RAM on Windows XP, running my 50% fragmented laptop while Firefox 17.0.1 has a few pages/tabs open (and up to 600,000 KB of memory eaten), and a few other applications are open, can cause the computer to go into molasses mode, where windows switching becomes painfully slow.

In testing out a wxPython application, I just found that after it was sitting unused-by-me and sort of running in the background while I used other programs, like Firefox, and then I switched to it, the main frame was responsive but then when I did a user action that caused a wxDialog to be launched, it took about 20 seconds for the dialog to appear. Yuck. I then used and closed that dialog, did the same type of action again, and now the dialog popped up almost instantly. (I should note that I am launching the whole app via Boa Constructor, an IDE).

I think this super-slow vs. fast dialog appearance discrepancy may be related to the “warm boot” of applications, in that when you close a program down Windows doesn’t really vacate the RAM of that program but sort of keeps it handy in case you need it again soon, but if you wait too long that RAM has to get used for something else.

So, question #1: is that thinking right? Do the instructions for how to make a dialog “hang around” when recently used and therefore dialogs launch much more quickly, but the instructions “fade away” if you haven’t launched a dialog in a few hours and so have to be loaded from disk again?

Question #2: Is there anything I could do about this to prevent it? I know the real answer is that my computer is to blame, but I also know that the reality is that there are still a lot of people who have old/slow computers (and sometimes far worse than mine, since, AFAIK, I don’t have much or any malware). If there is something that can be done to increase “snappiness”, it makes a huge difference, in my case, to usability of the application.

I haven’t tested this issue out on a py2exe’d version of my app, but will.

(And yes, I should get a better computer, and will…but in a way, this one has some value as a good test case for older computers).

Thanks,
Che

5

Thanks, Gadget/Steve and David. Yes, I kind of suspected there was not much if anything I could do programmatically, but I thought I’d check. Maybe it’s possible I can get a little more the illusion of responsiveness by having the dialog actually exist but be hidden (therefore all the waiting will be at the time of switching the frame), but that is probably more trouble than it’s worth.

Perhaps the best thing is to just let users know that if they experience too-slow performance they should consider improving their systems…probably the super-slow systems are mostly a small minority by now (and those that are still using them are unlikely to be using niche desktop software anyway).

Che

···

On Wed, Mar 26, 2014 at 6:17 PM, David Woods david@badgerchildhoodcancer.org wrote:

I seem to recall that on machines with those specs, adding RAM made a HUGE difference in the situation you describe, exactly because then the app you are switching to is less likely to have been swapped to the hard drive from RAM, as Gadget/Steve said.

This has nothing to do with wxPython, and py2exe probably won’t help just a ton. It’s an OS issue, not an application-specific issue.

David

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

On Wed, Mar 26, 2014 at 4:27 PM, Steve Barnes gadgetsteve@live.co.uk wrote:

On 26/03/14 21:07, C M wrote:

              I am one of a large number of slow computer

owners. With 1.7 GhZ and 1 GB or RAM on Windows XP,
running my 50% fragmented laptop while Firefox 17.0.1
has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open,
can cause the computer to go into molasses mode, where
windows switching becomes painfully slow.

            In testing out a wxPython application, I just found that

after it was sitting unused-by-me and sort of running in
the background while I used other programs, like
Firefox, and then I switched to it, the main frame was
responsive but then when I did a user action that caused
a wxDialog to be launched, it took about 20 seconds
for the dialog to appear. Yuck. I then used and closed
that dialog, did the same type of action again, and now
the dialog popped up almost instantly. (I should note
that I am launching the whole app via Boa Constructor,
an IDE).

          I think this super-slow vs. fast dialog appearance

discrepancy may be related to the “warm boot” of
applications, in that when you close a program down
Windows doesn’t really vacate the RAM of that program
but sort of keeps it handy in case you need it again soon,
but if you wait too long that RAM has to get used for
something else.

        So, question #1:  is that thinking right?  Do the

instructions for how to make a dialog “hang around” when
recently used and therefore dialogs launch much more
quickly, but the instructions “fade away” if you haven’t
launched a dialog in a few hours and so have to be loaded
from disk again?

      Question #2:  Is there anything I could do about this to

prevent it? I know the real answer is that my computer is to
blame, but I also know that the reality is that there are
still a lot of people who have old/slow computers (and
sometimes far worse than mine, since, AFAIK, I don’t have much
or any malware). If there is something that can be done to
increase “snappiness”, it makes a huge difference, in my case,
to usability of the application.

      I haven't tested this issue out on a py2exe'd version of my

app, but will.

    (And yes, I should get a better computer, and will...but in a

way, this one has some value as a good test case for older
computers).

      Thanks,

      Che

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to wxpython-users+unsubscribe@googlegroups.com.

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

If you only have 1GB of RAM, several other applications open and an

IDE then most of your, not latest used, applications memory
allocations are swapped to hard disk - when you swap the the
application that has been in background and try to do just about
anything the RAM that it was using has to be reconstructed from the
hard disk, and to make the space for it a lot of that from the
application that was running last has to be swapped out to disk
first. If your hard disk is fragmented and you don’t have a
permanently allocated swap space it also has to find the spare bits
of disk before doing that. Hence the very slow response - once you
are running from RAM you are fine.

To speed things up - close other Applications, De-fragment Disk,

Allocate at least the recommended swap file size as a permanent swap
file, don’t us compressed disk especially for swap disk , all
the usual tips. Keep in mind that support for XP ends next month.

Hope that helps.



Gadget/Steve

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

6

Just a thought ... but what would happen if you had a wxTimer running continually in the program and doing something innocuous? Would that force the O/S to keep it in memory? What if the dialog were instantiated but now shown and was somehow involved with the wxTimer?

And yes there are perhaps all kinds of reasons why that just might be a really bad idea.

Michael

···

On 3/26/2014 10:09 PM, C M wrote:

Thanks, Gadget/Steve and David. Yes, I kind of suspected there was not
much if anything I could do programmatically, but I thought I'd check.
Maybe it's possible I can get a little more the illusion of
responsiveness by having the dialog actually exist but be hidden
(therefore all the waiting will be at the time of switching the frame),
but that is probably more trouble than it's worth.

Perhaps the best thing is to just let users know that if they experience
too-slow performance they should consider improving their
systems...probably the super-slow systems are mostly a small minority by
now (and those that are still using them are unlikely to be using niche
desktop software anyway).

7

You could try turning RAM paging off,

That's a good suggestion, but I was trying to come up with a way to
programmatically help those users who, for whatever reason, will not or can
not take steps to enhance their computer's responsiveness--not speed up my
own computer (though, thanks, anyway, and I may try that). I guess my hope
was to give my applications, or any wxPython applications, the best chance
at running responsively on these old/slow systems. Probably a misguided
thought in the first place. :smiley:

8

You could use psutil: phymem_usage(), virtmem_usage() and
get_process_list() to determine when virtual memory is in use and
there are other processes running and possibly hogging memory then
warn the user that they need to close some down, you could even tell
them which it taking the most.
psutil: Gadget/Steve

···

On 27/03/14 04:51, C M wrote:

You could try turning RAM paging off,

          That's a good suggestion, but I was trying to come up

with a way to programmatically help those users who, for
whatever reason, will not or can not take steps to enhance
their computer’s responsiveness–not speed up my own
computer (though, thanks, anyway, and I may try that). I
guess my hope was to give my applications, or any wxPython
applications, the best chance at running responsively on
these old/slow systems. Probably a misguided thought in
the first place. :smiley:

–

  You received this message because you are subscribed to the Google

Groups “wxPython-users” group.

  To unsubscribe from this group and stop receiving emails from it,

send an email to wxpython-users+unsubscribe@googlegroups.com.

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

http://code.google.com/p/psutil/

9

C M wrote:

I am one of a large number of slow computer owners. With 1.7 GhZ and
1 GB or RAM on Windows XP, running my 50% fragmented laptop while
Firefox 17.0.1 has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open, can cause the
computer to go into molasses mode, where windows switching becomes
painfully slow.

Going in a separate direction, I have learned that Chrome is
significantly less memory-hungry than Firefox. I've moved almost
exclusively to Chrome on less-capable machines.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

10

Michael Hipp wrote:

Just a thought ... but what would happen if you had a wxTimer running
continually in the program and doing something innocuous? Would that
force the O/S to keep it in memory? What if the dialog were instantiated
but now shown and was somehow involved with the wxTimer?

That might keep the wxTimer handler in memory, but the problem is that
Python and wxPython are relatively large, and page management happens
using 4k-byte blocks. While you are keeping the wxTimer block warm, the
more general GUI sections of wxPython will still age out.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

11

I am one of a large number of slow computer owners. With 1.7 GhZ and
1 GB or RAM on Windows XP, running my 50% fragmented laptop while
Firefox 17.0.1 has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open, can cause the
computer to go into molasses mode, where windows switching becomes
painfully slow.

Microsoft (Not Responding) is not an operating system, as its name
already says:

Windows
Is
Not
Designed as an
Operating i.e.
Working
System

Question #2: Is there anything I could do about this to prevent it?
I know the real answer is that my computer is to blame,

No, it's Windows that is just obscenely ridiculous crap.

BeOS could decompress four simultaneous MPEG-4 streams without
dropping a frame, without any block artifacts, while perfectly remaining
responsive to user interaction in the Tracker - on late-90s hardware.

And Firefox is similar garbage as Windows, it's leaking memory like a
barrel without a bottom. Usually, you can reduce its memory consumption
by at least 50% by just quitting and restarting it (with the same
windows and tabs open).

Sincerely,

Wolfgang

12

Wolfgang Keller wrote:

I am one of a large number of slow computer owners. With 1.7 GhZ and
1 GB or RAM on Windows XP, running my 50% fragmented laptop while
Firefox 17.0.1 has a few pages/tabs open (and up to 600,000 KB of
memory eaten), and a few other applications are open, can cause the
computer to go into molasses mode, where windows switching becomes
painfully slow.

Microsoft (Not Responding) is not an operating system, as its name
already says:

Religious diatribes are not welcome here.

···

--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

13

>> I am one of a large number of slow computer owners. With 1.7 GhZ
>> and 1 GB or RAM on Windows XP, running my 50% fragmented laptop
>> while Firefox 17.0.1 has a few pages/tabs open (and up to 600,000
>> KB of memory eaten), and a few other applications are open, can
>> cause the computer to go into molasses mode, where windows
>> switching becomes painfully slow.
>
> Microsoft (Not Responding) is not an operating system, as its name
> already says:

Religious diatribes are not welcome here.

My statement is based on 25 years of empirical experience (Atari TOS,
MacOS "classic" as well as MacOS X, OS/2, BeOS, various commercial
Unixes, various Linux distributions, BSD etc. besides Windows), not
"religious" "belief".

Windows is a hopelessly dysfunctional heap of junk that can lock up to
the point where all you can do is to literally pull the plug (and take
the battery out for laptops) without *any* reason. And this has never
had anything to do with "slow hardware".

Sincerely,

Wolfgang

14

> >> can cause the computer to go into molasses mode, where windows
> >> switching becomes painfully slow.
> >
> > Microsoft (Not Responding) is not an operating system, as its name
> > already says:
>
> Religious diatribes are not welcome here.

  Google

Regards,
Karsten

···

--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

15

True -- but if one does want to get work done with old hardware, putting a
nice trim Linux system on it may be a way to get some more useful life out
of it...

But regardless of the relative quality and functionality of various
operating systems, many of us need to develop for the OS our users
need/want to use, so this is a good forum for discussion how to best adapt
tho those systems limitations.

Too bad about BeOS though -- that system really was way ahead of its time.
Shows you how market forces are much stronger than technical merit in
determining what we end up using...

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

···

On Fri, Mar 28, 2014 at 10:06 AM, Tim Roberts <timr@probo.com> wrote:

Religious diatribes are not welcome here.