vlr@litwin.com (Vic Rice) (10/25/90)
My group has been developing a reasonably large Motif application for about 18 months. Over the course of this development a significant problem has been slowly getting worse. The problem is the ever increasing time it takes for various popups to come up. Our development system: SCO ODT 1.0.0y ALR FlexCache 33/386 (Intel 80387 & Weitek) Paradise VGA Plus Multisyncing monitor (used in 800x600) Currently, the size of the load module is over 2 meg, unstripped. Popups that used to take 1 or 2 sec to appear completely now take as long as 15 sec. These popups contain various children (RowColumn, DrawingArea, etc). My perception is this degradation has been gradual, as we have added to the application. Are we causing this ?? Is there some memory/buffer management techniques we are overlooking ? I realize this is a somewhat vague question, but I don't really know where to start. We are new to X and Motif, so I suspect we are overlooking something obvious, I hope. I would appreciate any comments. -- Dr. Victor L. Rice Litwin Process Automation
klee@wsl.dec.com (Ken Lee) (10/26/90)
In article <1990Oct25.142436.9581@litwin.com>, vlr@litwin.com (Vic Rice) writes: |> My group has been developing a reasonably large Motif application for about |> 18 months. Over the course of this development a significant problem |> has been slowly getting worse. The problem is the ever increasing time |> it takes for various popups to come up. I don't know how much memory you have, but it sounds like a paging problem. Motif popups are created when they are realized, so popping them up means just mapping their windows. Your problem is probably that paging in the code that requests the map is very slow. I suspect that popping them up the second time will be quite a bit faster, since the code is already paged in. In the long run, there's probably not much you can do about this, aside from getting a faster CPU, faster disk, or more RAM. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
mikep@sco.COM (Mike Patnode) (10/26/90)
In article <1990Oct25.142436.9581@litwin.com> vlr@litwin.com (Vic Rice) writes: >My group has been developing a reasonably large Motif application for about >18 months. Over the course of this development a significant problem >has been slowly getting worse. The problem is the ever increasing time >it takes for various popups to come up. > >Our development system: >SCO ODT 1.0.0y >ALR FlexCache 33/386 (Intel 80387 & Weitek) >Paradise VGA Plus >Multisyncing monitor (used in 800x600) > >Currently, the size of the load module is over 2 meg, unstripped. Popups >that used to take 1 or 2 sec to appear completely now take as long as >15 sec. These popups contain various children (RowColumn, DrawingArea, etc). >My perception is this degradation has been gradual, as we have added to the >application. > >Are we causing this ?? Is there some memory/buffer management techniques >we are overlooking ? For starters, be sure you are linking with -lmalloc. This is a big win for memory performance. Note that libmalloc is a much more stringent about misuse of memory than libc. Also, whenever possible try to hide Popup menus via XtPopdown(), rather than creating and destroying them each time they are used. This may be obvious. Hope that helps. -- Mike Patnode The Santa Cruz Operation SCO Software Engineer 400 Encinal Street {ucscc,uunet}!sco!mikep mikep@sco.COM P.O. Box 1900 (408) 458-1422 Santa Cruz, CA 95061
krupczak@secola.Columbia.NCR.COM (Bobby Krupczak) (10/26/90)
>In article <1990Oct25.142436.9581@litwin.com>, vlr@litwin.com (Vic Rice) writes: > My group has been developing a reasonably large Motif application for about > 18 months. Over the course of this development a significant problem > has been slowly getting worse. The problem is the ever increasing time > it takes for various popups to come up. I am going to make the incredibly astute observation that since you are using SCO ODT, you are probably using SCO UNIX. A while back, I was working on porting a client/server type application to Interactive 2.2 and SCO XX. The SCO UNIX was a dog! I tried everything I knew to tune the SCO kernel. In through-put tests, the SCO was always dead last by a big margin. Have you turned off SCO's security stuff? Upon installation of SCO UNIX, they have all this security stuff turned on; if you turn it off, performance might improve slightly -- ours did. I think the gentleman from DEC had good suggestions also. Bobby
vlr@litwin.com (Vic Rice) (10/26/90)
mikep@sco.COM (Mike Patnode) writes: >In article <1990Oct25.142436.9581@litwin.com> vlr@litwin.com (Vic Rice) writes: >>My group has been developing a reasonably large Motif application for about >>18 months. Over the course of this development a significant problem >>has been slowly getting worse. The problem is the ever increasing time >>it takes for various popups to come up. >> >For starters, be sure you are linking with -lmalloc. This is a big win >for memory performance. Note that libmalloc is a much more stringent >about misuse of memory than libc. >Also, whenever possible try to hide Popup menus via XtPopdown(), >rather than creating and destroying them each time they are used. >This may be obvious. >Hope that helps. Many many thanks, Mike. The -lmalloc was right on the money. Adding -lmalloc made a drastic improvement in the performance of several aspects of our application, not just popups. We were doing XtPopdown() via a Motif call. I hope anyone developing Motif apps under SCO ODT pays attention to this. It makes a SIGNIFICANT difference. God, I love USENET. -- Dr. Victor L. Rice Litwin Process Automation
masa@hpsciz.HP.COM (Masayoshi Habu) (10/27/90)
Creating a dialog with lots of children is a memory-intensive operation. There are two suggestions for slow dialog creation. One is to avoid creating dialogs as much as possible. This means that whenever it is possible to reuse a dialog, do it. You probably can create a dialog when your program starts up, and use just map/unmap calls. The other is to use a faster memory allocation library. The original C malloc() was designed to use less memory while sacrificing time. A fast malloc() library might be available on your system which uses more memory, but less time. Another reason to avoid creating dialogs (widgets) was that XtDestroyWidget() used to cause memory leaks which eventually eat up all your memory and kill a process. Motif 1.1 and new Xt library has fix for this. Masa Habu
thp@westhawk.UUCP ("Timothy H Panton.") (10/28/90)
Vic Rice <dynsim1!vlr> writes: > Popups that used to take 1 or 2 sec to appear completely now take as long as > 15 sec The delay may not be in your application, but in the X Server, have a look at which process is burning the cpu time. The algorythms in R3 based servers are non optimal for large numbers of windows ( thus widgets) R4 made mapping conciderably faster. So find out if your server is R3 based and if so upgrade to R4 asap. Tim. +----------------------------------------------------------------------------+ |Tim Panton, Westhawk Ltd. "... avoiding vain and profane babblings." | |Phone: +44 928722574 -1 Timothy 6:20. | |uucp : ..!mcvax!ukc!westhawk!thp | |Paper: Westhawk Ltd. 26 Rydal Grove, Helsby, Cheshire, WA6 OET. UK. | +----------------------------------------------------------------------------+
jg@crl.dec.com (Jim Gettys) (10/30/90)
Some R3 based servers, (like the ones we currently ship on Ultrix, and the R4 based servers we'll ship in the not too distant future), already have the window manipulation speedups; in fact, the work we did was given to MIT and accounts for much of the improvement in R4 in this area. In the general case, the recommendation to use an R4 server is a good one. Other things which slow some people's implementations are slow malloc's, which the server and toolkits use heavily, and if you are paging significantly, you can just plain lose... The memory savings of R4 and some malloc versions can help greatly; the toolkits in general need some serious dieting on memory usage. - Jim
nick@esacs.UUCP (Nick Tsivranidis) (11/01/90)
In article <13270002@hpsciz.HP.COM>, masa@hpsciz.HP.COM (Masayoshi Habu) writes: > Creating a dialog with lots of children is a memory-intensive operation. > There are two suggestions for slow dialog creation. One is to avoid > creating dialogs as much as possible. This means that whenever it is > possible to reuse a dialog, do it. You probably can create a dialog > when your program starts up, and use just map/unmap calls. The other Yes, but the problem is that dialogs are (usually) modal boxes and the 'parent' widget is very important (if you want the dialog centered on the window that produced it). Since reparenting a widget is not a smart idea, one is stuck with the Create/Destroy mechanism (which as you point out doesn't work right). This is yet another indication that 'something' was not well designed in this X11/Xt/Xm world we live in. But, such is life.... - nick - -- Nick Tsivranidis @ ESA Software srl - ITALY uunet: ....mcsun!i2unix!esacs!nick voice: (0039) 541 741113 fax: (0039) 541 742153
asente@adobe.com (Paul Asente) (11/03/90)
In article <1220@esacs.UUCP> nick@esacs.UUCP (Nick Tsivranidis) writes: > Yes, but the problem is that dialogs are (usually) modal > boxes and the 'parent' widget is very important (if you want > the dialog centered on the window that produced it). Since > reparenting a widget is not a smart idea, one is stuck > with the Create/Destroy mechanism (which as you point out > doesn't work right). > > This is yet another indication that 'something' was not > well designed in this X11/Xt/Xm world we live in. But, > such is life.... In this case, what is wrong is your understanding of how popups work in Xt. The parent of a popup widget is not like the parent of a regular widget; the popup child's window is not a child of the parent's window. Any widget can cause any popup widget to appear; it doesn't have to be the parent. You can move or resize a popup when you pop it up by using the XtNpopupCallback resource. -paul asente asente@adobe.com ...decwrl!adobe!asente