Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!deccrl!bloom-beacon!dont-send-mail-to-path-lines
From: jordan@tcs.COM (Jordan Hayes)
Newsgroups: comp.windows.x
Subject: Re: Impact of Running Several Large X Programs
Message-ID: <9104301628.AA26402@dwight.tcs.com>
Date: 30 Apr 91 16:28:06 GMT
References: <1991Apr30.024458.1020@jpl-devvax.jpl.nasa.gov>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Teknekron Communications Systems, Inc., Berkeley, CA.
	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 perfor
Lines: 24

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 ...

/jordan