[comp.windows.x] Server memory usage

crovella@cs.Buffalo.EDU (Mark Crovella) (09/13/88)

Can anyone summarize the various X functions that result in server
memory being allocated (and their relative costs)?  We are running
out of server memory frequently with a modest number of windows
onscreen (maybe about 15).  My suspicion is that we are creating
more GCs than necessary and larger pixmaps than necessary but I 
may well be overlooking something.

We are using X11r2 under Ultrix and IBM-PC's as servers (running
PC-Xsight from Locus, Inc.).  ... also GNU C++ and InterViews ...

Thanks for any insights here.

Mark Crovella           "Reflect, ponder, excogitate, reply." - J.Joyce
uucp:	  ..!{ames,boulder,decvax,rutgers}!sunybcs!crovella
internet: crovella@cs.buffalo.edu         bitnet: crovella@sunybcs.bitnet

RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (09/27/88)

    Date: 13 Sep 88 12:56:47 GMT
    From: sunybcs!crovella@rutgers.edu  (Mark Crovella)

    Can anyone summarize the various X functions that result in server
    memory being allocated (and their relative costs)?

Not easily.  This can vary quite a bit depending on how the server is
implemented.  Also, you don't say whether you want the information at
the protocol, Xlib, or toolkit level; the higher you go, the harder it
gets.  All protocol requests that create resources result in memory
being allocated, but many other requests can cause allocations as well,
at least on a temporary basis.  If you look through the server header
files in the MIT distribution, you can probably get a fairly good idea
of how big things like windows, gcs, and pixmaps are in many servers.

    We are running
    out of server memory frequently with a modest number of windows
    onscreen (maybe about 15).  My suspicion is that we are creating
    more GCs than necessary and larger pixmaps than necessary but I 
    may well be overlooking something.

We've had this idea for some time of writing a "statistics server"
that acted as a transparent filter to a real server, but gathered
all kinds of data along the way.  Seems like it would be handy for
you.  Someday hopefully we'll find the resources to do it.

ea08+@andrew.cmu.edu (Eric A. Anderson) (01/23/91)

Actually, the problem with tvtwm is worse.  With saveunder a legal
parameter for the X server, when you bring up a window with saveunder
in the default X server, it saves the entire virtual root window.
(this is fixed in R5).  It was fun to watch though, on a color
decstation, you would start with a 2000k server, bring up a menu, and
poof, the server breaks 10megs.
You can fix this by recompiling the server to not do save unders, or
backing stores or something like that. (It works, I did it, don't
remember exactly how, Use the Source.)
          -Eric
*********************************************************
"My life is full of additional complications spinning around until
 it makes my head snap off."
           -Unc. Known.
"You are very smart, now shut up."
           -In "The Princess Bride"
*********************************************************

toivo@antlia.cc.uwa.oz.au (Toivo Pedaste) (01/23/91)

When I read the man entry on Xserver (as well as the on on Xsun) there turns out
to be a parameter (ld) which is used to limit the data space used by the server.
This seems to work fine is limiting the size of the server.
--
	Toivo Pedaste				ACSNET:   toivo@antlia.cc.uwa.oz
	WARCC,					INTERNET: toivo@antlia.cc.uwa.oz.au
	University of Western Australia		Phone:    (09) 380 2605

colas@avahi.inria.fr (Colas Nahaboo) (01/23/91)

In article <wbbCfji00awVM8nyBw@andrew.cmu.edu>, ea08+@andrew.cmu.edu (Eric A.
Anderson) writes:
> You can fix this by recompiling the server to not do save unders, or
> backing stores or something like that. 

Simpler: launch your server with "-su -bs" command line options
(I could not live without it)

--
Colas Nahaboo, Bull Research France -- Koala Project -- GWM X11 Window Manager
Internet: colas@mirsa.inria.fr, Phone: (33) 93.65.77.70, Fax: (33) 93 65 77 66
INRIA Sophia, 2004, rte des Lucioles, B.P.109 - 06561 Valbonne Cedex, FRANCE