larryc@puente.jpl.nasa.gov (Larry Carroll) (04/30/91)
We have an Ethernet network of a bunch of DECstation 3100s running X & Motif. Currently the X is DEC's DECwindows, which is X11R3 (or so I'm told), but we're soon migrating to a generic X11R4. There's also a VAX with about a gigabyte of disc space that we'll use to store raster maps. All systems run Ultrix & are NFS'd together. For some reason I don't fully understand, the lead designer wants to allow users to launch as many copies of a map-viewing & -annotating program as they choose to. I wonder at the impact on performance this is likely to have -- each of the the map programs runs at least 5 MBytes, & when we're done enhancing them I'd guess they'll end up 8-10 MBs, or even larger. Since there's only (!) 16 MBs of RAM, it seems likely that more than one copy of this large program is likely to cause disc thrashing, especially since users are likely to also have windows up with a mail handler, word processor, and a few other such utilities. My question is: where can I get some studies on this problem? What tools can I use to measure performance? And (for anyone with a pipeline to tomorrow!) are there any enhancements to Ultrix (such as shared libraries) or X Windows that we can expect anytime soon that will improve performance?
jordan@tcs.COM (Jordan Hayes) (04/30/91)
I ran into this question a while back, and what I did was write my
application so that it was confined to a single structure that included
a display connection[*] and an applicationShell, and no global
variables (except the XtAppContext). This way, "launching another
copy" became something I did within the same process. I saved *tons*
of memory, and gazillions of context switches :-)
[*] The reason each instance had its own Display was the Xrm database
is managed on a per-display basis, and I wanted to be able to name
each "instance" differently if needed (to set the default fonts,
colors, etc). Fortunately, I never ran into file descriptor
problems ...
By the way, the performance of this setup even with 2 "instances" was
better than having two processes around, even though the work being
done by the instances was fairly hefty. I found I could go to several
dozen top-level windows before things started getting sluggish. I
could only run 4 copies of the individual process case before the
machine started to thrash.
I was using Motif1.1, and even with shared libraries (on a Sun),
the memory constraint was most alarming ...
/jordanchuck@Morgan.COM (Chuck Ocheret) (05/07/91)
> I ran into this question a while back, and what I did was write my > application so that it was confined to a single structure that included > a display connection[*] and an applicationShell, and no global > variables (except the XtAppContext). This way, "launching another > copy" became something I did within the same process. I saved *tons* > of memory, and gazillions of context switches :-) This approach is valuable in a number of situations. It vastly reduces startup time of all but the first window. Another advantage is that if interfaces are written with this potential use in mind, the UI code is generally more modular. There are fewer global variables since all of the information for each connection must be maintained in state structures. You can easily drop completely different applications into the same program to save on resources. > I was using Motif1.1, and even with shared libraries (on a Sun), > the memory constraint was most alarming ... > > /jordan Actually the biggest constraint when using Motif1.1 is that if you close one of your display connections, you will not be able to open up any more. This is due to a Motif gc caching bug which I experienced and /jordan found and reported. I don't expect this to be fixed anytime soon based on the last report from OSF. This makes this entire technique completely unusable in most environments. ~chuck -- +--------------------+ Chuck Ocheret +---------------+ |chuck@fid.Morgan.COM| Morgan Stanley & Co., Inc. |(212) 703-4474 | | Duty now ... |19th Floor, 1251 Avenue of the Americas|for the future.| +--------------------+ New York, N.Y. 10020 USA +---------------+