marcs@SLC.COM (Marc San Soucie) (03/27/91)
Rob Hagens writes: > We are having some performance problems with our Motif application when > it runs on a Decstation 3100. Our application is a mail reading/composing > tool. Each window is fairly complex in that is has menus, buttons, > frames, scrolling windows, etc. The performance issue is that it often > takes 8-14 seconds (elapsed time) for all the widgets to be created > and displayed on the screen. Also, the delay when the window is raised (after > part of it was hidden) is also very significant. > > Our runtime image is huge (over 5 Meg). Does anyone else have an application > that is this big when compiled on a risc machine? Could the delay be > due to paging ? Does anyone else have any performance problems of > this type? You're right - it's huge. With a 5 Meg image, and the creations of scads of widgets, you can expect your memory requirements to approach 8 Meg. If you are running this monster on an 8 Meg machine, consider 8-14 seconds a gift. Even on a 16 Meg machine, executables like this one can start hammering at the disk. In a situation such as yours, here's what I would do. The spirit of Mr. Wizard is strong around here... 1) Run the thing, and put your ear next to the disk drive. Try to pay attention to the when the chattering stops. If it continues throughout the initial display, kill it and run it again. Bring up and bring down a bunch of dialogs, repeatedly. If you always hear disk chatter, you're probably in paging debt. 2) After you've exercised the program a bit, leave it running, go to a shell (preferably on another machine) and get a 'ps' status. Check the size and RSS of the image. If either one is even close to your memory size, you're in trouble. Think about using shared libraries to cut back on some of it. 3) If the disk is quiet and sizes are reasonable, build yourself a profiling version of libXm.a, libXt.a, libX11.a, and all your own code. Run it. Run prof or gprof and examine the results. Most likely, you will find an enormous amount of time being spent in a small number of Xm and Xt routines. Use them less. If the time is scattered evenly across dozens of routines, you're up the creek. 4) Are you using UIL? Think about not doing so as a possible cure. Save both space and time. 5) Run "nm -n" on your executable and figure out who's taking up your 5 Megs. If it's your own code, rewrite it with space conservation in mind. If it's someone else's, complain bitterly and look for other solutions. Good times! Marc San Soucie Servio Corporation Beaverton, Oregon marcs@slc.com
thp@westhawk.UUCP ("Timothy H Panton.") (03/29/91)
hagens%edu.wisc.cs writes: > Also, the delay when the window is raised (after > part of it was hidden) is also very significant. If you have large numbers of windows (~1000) then you may find that the server speed is the problem. We found that moving from an R3 based server to an R4 one made a vast improvment in this case. > Our runtime image is huge (over 5 Meg). Again you should look to see what size the server is too, we found that the combined size of client and server often took us into paging. More memory helps here. Tim. +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. "Do not meddle in the affairs of Wizards, for | |Phone: +44 928722574 they are subtle and quick to anger." | |Email: thp%westhawk.uucp@ukc.ac.uk The Lord of the Rings. | |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | +----------------------------------------------------------------------------+
brett@solar.card.inpu.oz.au (Brett Sealey) (04/02/91)
hagens%edu.wisc.cs writes: [complaints about speed of an overloaded system] >> Our runtime image is huge (over 5 Meg). stripping a binary gives good savings in size. Naturally don't do this while you are still debugging the code :-) A possible simple solution for your problems. Cheers, ______________________________________________________________________________ __ __ ___ ____ ____ /__) /__) /_ / / brett@solar.card.inpu.oz.au /__) / \ /__ / / Brett Sealey ______________________________________________________________________________