Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!SLC.COM!marcs
From: marcs@SLC.COM (Marc San Soucie)
Newsgroups: comp.windows.x.motif
Subject: Re: MOTIF performance woes
Message-ID: <9103262049.AA06913@servio.SLC.COM>
Date: 26 Mar 91 20:49:45 GMT
References: <9103261802.AA14061@janeb.cs.wisc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 55

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