Re: Iconized application takes looooong to wake up

Juan C. Gil wrote:

Upon application start: 233 Mb
Upon iconifying it: 2.7 Mb
Quickly uniconifying it: 118Mb, takes no time
Leaving it iconified for some hours and uniconifying it: 118Mb, takes
3:30 minutes

The numbers seem a bit extreme, but the logic is straight-forward
enough: likely, your application is getting paged out by the operating
system.

When you restore the window quickly, the OS has not, in the interim,
decided that the application was idle long enough to swap out. If you
leave it sit long enough, the OS assumes (rightly) that it is not doing
anything, and makes room in core for active programs.

Short of running with no page file, or a very small one, I can't think
of any way around this on any modern OS.

What you can do is attempt to minimize the hit.

First, I can only think of two reasons, off the top of my head, why it
would take 3 minutes to reload the application when it is restored:
recoverable hardware problems (not likely, and won't likely happen on
multiple machines), or lack of resources. For the latter: are these
machines all running Vista on 256MB RAM (or something not quite so
extreme, but still resource-starved)? That would do it: as the
application gets swapped in, everything else, save vital OS functions,
must get swapped out, including applications currently on display.

I've seen machines low on resources thrash for 20 hours on a
memory-intensive task in an application with poor memory management.
Bringing up the task manager would take 40 minutes, and add near an hour
to the entire operation. You may have a milder form of this affliction.

What, if anything can you do to reduce the amount of "stuff" displayed
in that minimized window? Windows is a pig (IIRC, showing console and
one toplevel with two widgets can take 2-3MB core, 7-8MB VM), but
perhaps you can reduce the number of items shown.

I've also seen Windows choke on redrawing windows with too many widgets.
Try this: make a toplevel with a grid of 40x50 buttons. Sometimes it
will even refuse to draw them all, after which it won't open new
windows, post menus, etc. (even in other applications). I believe
there's a resource leak in the OS.

Perhaps you could trade some widgets for a canvas, or a single widget
displaying an image to which you write data. Perhaps you can display
things in the window in tabs, so it is not all live at once.

I added a periodic self-scheduling procedure which did nothing and the
situation didn't changed a bit. Nevertheless, if this procedure
displays some text in the MMI the situation changes as follows:
....
Leaving it iconified for some hours and uniconifying it: 118Mb, takes
1:15 minutes

It's not simply that the application is busy, it's that the resources
associated with this "MMI" are busy, so only part of the application is
getting swapped out. Maybe there's something you can do to keep the
rest of the UI widgets busy. Maybe it's that some aspect of the
resources for displaying a window cannot be kept active when the window
is minimized. That, I don't know, but it's worth playing with.

Also, your interface is under your control. If your procedure adds
something you don't want, remove it. My guess is that it is not the
periodic procedure that improves reload time, but the fact that the
interface has changed, so you may have to effect the change, wait until
it has had a chance to recalculate, then remove the change; that is,
enter the event loop, otherwise you may negate the positive effects of
the UI change.

Just my thoughts...

--
MKS
.

Loading