From: art@cs.UAlberta.CA (Art Mulder)
Subject: comp.windows.x: Getting more performance out of X.  FAQ
Followup-To: poster
Summary: This posting contains a list of suggestions about what you can do to get the best performance out of X on your workstation -- without buying more hardware.
Keywords: FAQ speed X 
Reply-To: art@cs.ualberta.ca (Art Mulder)
Organization: University of Alberta, Edmonton, Canada
Date: Wed, 16 Dec 1992 19:00:20 GMT

Archive-name: x-faq/speedups
Last-modified: 1992/12/16

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

	    HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting

  More RAM, Faster CPU's, More disk space, Faster Ethernet...  These are
  the standard responses you get when you ask about how to make your
  workstation go faster.

  Well, more hardware isn't always an option, and I wonder if more
  hardware is really always even a necessity.

  This "FAQ" list is a collection of suggestions and ideas from different
  people on the net on how you can the best possible performance from your
  workstation, WITHOUT PURCHASING MORE HARDWARE.

  This document is specifically concerned with X.  I realize that there are
  a whole host of other factors that affect the performance of a
  workstation.   Perhaps at some point, this document will grow into a
  generalized "System Performance Tuning" document, but for now our focus is
  on X.
	[ Note: People seriously interested in the whole area of system
	performance, might want to look at the O'Reilly nutshell book
	"System Performance Tuning" by Mike Loukides.  I've seen it,
	but not read it, so I can't comment on its content.  --ed.]

-----------------
Table of Contents
-----------------
  1. What about the "Other X FAQ"?
! 2. Window Managers
  3. The X Server
       Which Server?
       Starting your Server
       Fonts
!      About the Resources File
       Define Your Display Properly
! 4. Clients
!      A Better Clock for X
       A Better Terminal Emulator for X
  5. Miscellaneous Suggestions
       Pretty Pictures
       A Quicker Mouse
       Programming Thoughts
!      Say What!?
  6. Other Sources of Information
  7. Author & Notes
  
-----------------------------
What about the "Other X FAQ"?
-----------------------------

  David B. Lewis (faq%craft@uunet.uu.net) maintains the informative and
  well written "comp.windows.x Frequently Asked Questions" document.
  Its focus though, is on generally useful X information, while this
  FAQ is concerned with the issue of performance.

  The comp.windows.x FAQ does address the issue of speed, but only with
  regards to the X server.  The gist of that topic seems to be:
	"Use X11R5, it is faster than R4".
  (Please see the X FAQ for complete details).

  Performance is a subjective issue.  The individual user must balance
  `speed' versus `features' in order to come to a personal decision.
  Therefore this document can be be expected to contain many subjective
  opinions in and amongst the objective facts.

---------------
Window Managers
---------------

  There are a lot of window managers out there, with lots of different
  features and abilities.  The choice of which to use is by necessity a
  balancing act between performance and useful features.  At this
  point, most respondents have agreed upon "twm" as the best candidate
  for a speedy window manager. 

  A couple of generic tricks you can try is turning off unnecessary
  things like "zooming" and "opaque move".  Also, if you lay out your
  windows in a tiled maner, you reduce the amount of cpu power spent
  in raising and lowering windows.  
				    Joe English (joe@trystero.art.com)

  I've found that a good font for tiling is 7x13 (aka:
  -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 ) It is
  the biggest font I have found that I can use on a SPARC ELC and still
  get two 80 column terminal windows side-by-side on the display with
  no overlap.  Other suggestions will be accepted.

------------
The X Server
------------

Which Server?
- - - - - - -

  Doesn't the old saying go: "Use the right tool for the job"?  This
  applies to the X11 server also.  Make sure that your server is a
  proper match for your hardware platform.  If you have a monochrome
  monitor, use a monochrome X11 server.

  On my Monochrome Sun ELC, I haven't noticed much difference between
  the Xsun (colour) server and XsunMono, however it was pointed out to
  me that XsunMono is about 800k smaller and therefore should contribute
  to less paging.  
         [ thanks to: Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk),
                        Michael Salmon (Michael.Salmon@eos.ericsson.se) ]

  How your server was compiled can also make a difference.  Jeff Law
  (law@schirf.cs.utah.edu) advises us that on a Sun system, X should
  be compiled with gcc2.* or with the unbundled Sun compiler, and *not*
  use the the SunOS 4.1.1 bundled compiler.  You can expect to get
  "*very* large speedups in the server" that way.  I would assume that
  similar results would occur if you used one of the other popular
  high-quality commercial compilers on the market.

Starting your Server
- - - - - - - - - - -

  Joe English (joe@trystero.art.com) :
    If you start up a lot of clients in your .xsession or whatever, sleep
    for a second or two after launching each one.  After I changed my
    .xclients script to do this, logging in actually took *less* time...
    we have a heavily loaded system without much core, though.

  This sounds crazy, but I tried it, and it works!  

  Warner Losh (imp@Solbourne.COM) provided me with a good explanation of
  why this works, which I have summarized here:

    When you start up an X server it takes a huge amount of time to
    start accepting connections.  A lot of initialization is done by
    the server when it starts.  This process touches a large number of
    pages.  Any other process running at the same time would fight the
    server for use of the CPU, and more importantly, memory.  If you
    put a sleep in there, you give the Server a chance to get itself
    sorted out before the clients start up.

    Similarly, there is also a lot of initialization whenever an X
    client program starts: toolkits registering widgets, resources
    being fetched, programs initializing state and "databases" and so
    forth.  All this activity is typically memory intensive.  Once this
    initialization is done ("The process has reached a steady state"),
    the memory usage typically settles down to using only a few pages.
    So, by using sleeps to stagger the launching of your clients in
    your .Xinitrc , you avoid them "fighting" each other over your
    workstations limited resources

  This is most definitely a "Your Mileage May Vary" situation, as there
  are so many variables to be considered: available RAM, local swap
  space, load average, number of users on your system, which clients
  you are starting, etc.

  Currently in my .xinitrc I have a situation like:
	(sleep 1; exec xclock ) &
	(sleep 1; exec xbiff ) &
	(sleep 1; exec xterm ) &
	(sleep 1; exec xterm ) &
	(sleep 1; exec xterm ) &

  I've experimented with:
	(sleep 1; exec xclock ) &
	(sleep 2; exec xbiff ) &
	(sleep 3; exec xterm ) &
	(sleep 4; exec xterm ) &
	(sleep 5; exec xterm ) &

  I've even tried:
	(sleep 2; exec start_X_clients_script ) &
  and then in start_X_clients_script I had:
	(sleep 1; exec xclock ) &
	(sleep 1; exec xbiff ) &
	(sleep 1; exec xterm ) &
	(sleep 1; exec xterm ) &
	(sleep 1; exec xterm ) &

    [ The idea with this last one was to make sure that xinit had
    completely finished processing my .xinitrc, and had settled down
    into a "steady state" before the sleep expired and all my clients
    were launched. ]

  All of these yielded fairly comparable results, and so I just stuck with
  my current setup, for its simplicity.  You will probably have to
  experiment a bit to find a setup which suits you.

Fonts
- - -

  Loading fonts takes time, and RAM.  If you minimize the number of fonts
  your applications use, you'll get speed increases in load-up time.

  Farrell McKay (fbm@ptcburp.ptcbu.oz.au) :
    One small point I've noticed (not specifically related to R5) is that
    clients will always start up more quickly if they don't have to load a
    new font into the server.  So I only use two or three fonts throughout
    the whole of my X environment.  Sometimes I need to use a Kanji font
    (for my work) at intervals throughout the day, so in the morning I
    start up xfd with that font (that loads it into the server), iconify
    it, and leave it there for the rest of the day.  Pre-loaded fonts sure
    cut down initialization time.

  Joe English (joe@trystero.art.com) :
    Carefully choose a small number of fonts (one fixed-width, one roman,
    one sans-serif, one large one, whatever else you need) and
    reconfigure all the applications you use to use only those fonts.
    This will conserve server resources and make applications start up
    faster.  Loading fonts takes a long time.

  Oliver Jones (oj@roadrunner.pictel.com):
    Keep fonts local to the workstation, rather than loading them over nfs.
    If you will make extensive use of R5 scalable fonts, use a font server.

About the Resources File
- - - - - - - - - - - - -

  Joe English (joe@trystero.art.com) :
    Keep your .Xresources and .Xdefaults file small.  Same effect as
    [reducing the number of fonts].  

  In your .Xdefaults (.Xresources) file, try just putting the minimum
  amount of resources that you want to have available to all your
  applications.  For example:  *reverseVideo: true

  Then, separate your resources into individual client-specific
  resource files.  For Example: I store mine in $HOME/lib/app-defaults.
  In my .login file I set the environment variable XUSERFILESEARCHPATH:
	  setenv XUSERFILESEARCHPATH $HOME/lib/app-defaults/%N

  So, when I launch an xterm, it loads its resources from
  ...app-defaults/XTerm.  Xdvi finds them in .../app-defaults/XDvi,
  and so on and so forth.  Not all clients follow the same class-naming
  convention, so you may have some fun figuring out what to call the
  resource file (xterm? Xterm? XTerm?).  In general, try following the
  standard XXxxx pattern first.

  This method of organizing your personal resources has the following
  benefits:

  - Easier to maintain/ more usable.

  - Fewer resources are stored in the X server in the RESOURCE_MANAGER
    property.  As a side benefit your server may start fractionally
    quicker, since it doesn`t have to load all your resources.

  - Applications only process their own resources, never have to sort 
    through all of your resources to find the ones that affect them.

  - the application that you are interested in has to load an additional
    file every time it starts up.  This doesn't seem to make that much of a
    performance difference, and you might consider this a huge boon to
    usability.  If you are modifying an application's resource database,
    you just need to re-run the application without having to "xrdb" again.

  This is all documented in the Xt Specification (pg 125 & 666).
		    [Thanks to: Kevin Samborn (samborn@mtkgc.com)
		     and Michael Urban (urban@cobra.jpl.nasa.gov) ]

  The "comp.windows.x Frequently Asked Questions" FAQ list contains an
  excellent explanation of how these environment variables work.

  NOTE: xrdb will by default run your .Xdefaults file through cpp.
	When your resources are split out into multiple resource files
	(as described above) and then loaded by the individual client
	programs, they will NOT be processed first through cpp.  
	WATCH OUT FOR THIS!!

	I had C style comments in my .Xdefaults file, which cpp
	stripped out.  When I switched to this method of distributed
	resource files I spent several frustrating days trying to
	figure out why my clients were not finding their resources.  Xt
	did *NOT* provide any error message when it encountered those C
	style comments in the resource files, it simply silently
	aborted processing that resource file.

	The loss of preprocessing (which can be very handy, e.g. ``#ifdef
	COLOR'' ...) is enough to cause some people to not be interested in
	this method of resource management.

  You may also run into some clients which break the rules.  For example,
  neither Emacs (18.58.3) nor Xvt (1.0) will find their resources if they
  are anywhere other than in .Xdefaults.

  On other ``gotcha'' to watch out for is starting up a client on a
  machine that does not share files with the machine where your
  resources are stored.   In this case your client will not find its
  resources.  Loading all your resources into the server will guarantee
  that all of your clients will always find their resources.
	                            Casey Leedom (casey@gauss.llnl.gov)

Define Your Display Properly
- - - - - - - - - - - - - - -

  Client programs are often executed on the same machine as the server.  In
  that situation, rather than setting your DISPLAY environment variable to 
  "<hostname>:0.0", where <hostname> is the name of your workstation, you
  should set your DISPLAY variable to "unix:0.0" or ":0.0".  By doing this
  you access optimized routines that know that the server is on the same
  machine and use a shared memory method of transferring requests.
			[thanks to Patrick J Horgan (pjh70@ras.amdahl.com)]

  See the _DISPLAY NAMES_ section of the X(1) man page for further
  explanation of how to properly set your display name.

-------
Clients
-------

  If you only have a few megabytes of Ram then you should think
  carefully about the number of programs you are running.  Think also
  about the _kind_ of programs you are running.  For example:  Is there
  a smaller clock program than xclock?

  Unfortunately, I haven't really noticed that programs advertise how large
  they are, so the onus is on us to do the research and spread the word.

  [ Suggestions on better alternatives to the some of the standard clients
  (eg: Xclock, Xterm, Xbiff) are welcome.  --ed.]

  One thing to note on systems with shared libraries, is that once Xaw,
  Xt, Xlib, etc are loaded, they don't have to be loaded again.  So if
  you already have an Athena program loaded, xclock won't add much to
  the load.  This is an argument against non-Athena programs, that load
  extra code.  The moral of this story is to keep to one set of
  libraries -- don't mix your toolkits (e.g. XView and Xt).
      Duncan Sinclair (sinclair@dcs.gla.ac.uk | sinclair@uk.ac.gla.dcs) 

A Better Clock for X
- - - - - - - - - - -

  Richard Hesketh (rlh2@ukc.ac.uk) :
    xbiff and xclock are written using the X toolkit and are therefore
    rather large ...

  Duncan Sinclair (sinclair@dcs.gla.ac.uk) told me about ``xcuckoo'', which
  displays a clock in the title bar of *another* program.  Saves screen real
  estate.  I haven't tried this one out yet.  Find it on export...

  der Mouse (mouse@Lightning.McRCIM.McGill.EDU) :
    For your consideration I offer mclock, my clock program.  It is
    non-Xt-based, which alone should help, and is extensively
    configurable:  it can be made to look very much like MIT oclock, or
    mostly like xclock purely by changing resources.

    You can get this by anonymous ftp from larry.mcrcim.mcgill.edu
    (132.206.1.1), /X/mclock.shar

  I've tried this clock program out, and it works fine, but I haven't tried
  any extensive testing to see how it compares to xclock in resource
  consumption.  One point: don't let the size of the executable fool you.
  The binary on my site is about 2.5 times the size of Xclock, but the
  author pointed out to me that mclock does *not* drag in Xaw, Xmu, or Xt,
  which Xclock does.  Therefore, it should be lighter when running.

  Of course, the ultimate clock --- one that consumes no resources, and 
  takes up no screen real estate --- is the one that hangs on your wall.
  :-) 

A Better Terminal Emulator for X
- - - - - - - - - - - - - - - - -

  From the README file distributed with xterm:

  +-----
  |		 Abandon All Hope, Ye Who Enter Here
  |
  | This is undoubtedly the most ugly program in the distribution.
  | ...
  +-----

  Ugly maybe, but at my site it's still the most used.  I suspect that
  xterm is one of the most used clients at many, if not most sites.
  Laziness?  Isn't there a better terminal emulator available?  See below.

  If you must use xterm, you can try reducing the number of saveLines
  to reduce memory usage.  [ Oliver Jones (oj@roadrunner.pictel.com),
                   Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk) ]

1) Xvt

  Richard Hesketh (rlh2@ukc.ac.uk) :
    ... if you don't need all the esoteric features of xterm, then get
    hold of xvt from export.lcs.mit.edu:/contrib/xvt-1.0.tar.Z, it was
    written here just to save swap space as xterm is rather a hog!

  I've since obtained and am evaluating 'xvt' and it does seem to me
  to be noticeably faster than xterm, while yet coming off as a full
  featured "clone" of xterm -- you don't even have to rename your xterm
  resources as xvt pretends to be XTerm.  It is missing a few xterm
  features to which I've grown accustomed, but I'm giving it a try.

2) mterm

  der Mouse (mouse@Lightning.McRCIM.McGill.EDU) :
    I also have my own terminal emulator.  Its major lack is
    scrollback, but some people like it anyway.  It can be had from [
    larry.mcrcim.mcgill.edu (132.206.1.1) ], in
    /X/mterm.src/mterm.ball-o-wax.

-------------------------
Miscellaneous Suggestions
-------------------------

Pretty Pictures
- - - - - - - -

  One of the things I did when first learning to use X, was experiment with
  using different images as the background on my display.  (via xsetroot, or
  xphoon, etc).  I soon abandoned this practise for some very good reasons:

  - The more complicated your root window bitmap, the slower the server
    is at redrawing your screen when you reposition windows (or redraw, etc)

  - These take up RAM, and CPU power.  I work on a Sun SPARC ELC with 8mb
    RAM and I'm looking for more power, I can't comprehend it when I see
    people with a 4mb Sun 3/60 running xphoon as their root window.

  If you're anything like me, you need all the screen real estate
  that you can get for clients, and so rarely see the root window anyway.
		      [ Thanks to Qiang Alex Zhao (azhao@cs.arizona.edu) 
			for reminding me of this one. --ed.]
A Quicker Mouse
- - - - - - - -

  Using xset, you can adjust how fast your pointer moves on the screen
  when you move your mouse.  I like to be able to send my pointer
  across the screen with just a flick of the wrist, and so I use
  "xset m 5 10" in my .xinitrc file.  See the xset man page for further
  ideas and information.

  Hint: sometimes you may want to *slow down* your mouse tracking for
  fine work.  To cover my options, I have placed a number of different
  mouse setting commands into menus in my window manager.  
  e.g. (for twm) :
      menu "mouse settings"
      {
        "Mouse Settings:"			f.title
	"  Very Fast"				! "xset m 7 10 &"
	"  Normal (Fast)"			! "xset m 5 10 &"
	"  System Default (Un-Accelerated)"	! "xset m default &"
	"  Glacial"				! "xset m 0 10 &"
      }

Programming Thoughts
- - - - - - - - - - -

  Joe English (joe@trystero.art.com) :
    To speed up applications that you're developing, there are tons of
    things you can do.  Some that stick out:

    * For Motif programs, don't set XmFontList resources for individual
      buttons, labels, lists, et. al.; use the defaultFontList or
      labelFontList or whatever resource of the highest-level manager
      widget.  Again, stick to as few fonts as possible.

    * Better yet, don't use Motif at all.  It's an absolute pig.

    * Don't create and destroy widgets on the fly.  Try to reuse them.
      (This will avoid many problems with buggy toolkits, too.)

    * Use a line width of 0 in GCs.  On some servers this makes a HUGE
      difference.

    * Compress and collapse multiple Expose events.  This can make the
      difference between a fast application and a completely unusable
      one.

  Francois Staes (frans@kiwi.uia.ac.be) :
    Just a small remark: I once heard that using a better malloc
    function would greatly increase performance of Xt based
    applications since they use malloc heavily. They suggested trying
    out the GNUY malloc, but I didn't find the time yet. I did some
    tests on small programs just doing malloc and free, and the
    differences were indeed very noticeable ( somewhat 5 times faster)

  [ Any confirmation on this from anyone?  --ed.]

Say What!?
- - - - - - 

  Some contributors proposed ideas that seem right off the wall at first:

  David B. Lewis (by day: dbl@osf.org, by night: david%craft@uunet.uu.net) :
    How about this: swap displays with someone else. Run all your programs
    on the other machine and display locally; the other user runs off your
    machine onto the other display. Goal: reduce context switches in the
    same operation between client and server.

  I'm not in a situation where I can easily try this, but I have received
  the following confirmation...

  Michael Salmon (Michael.Salmon@eos.ericsson.se):
    I regularly run programs on other machines and I notice a big
    difference. I try to run on a machine where I will reduce net usage
    and usually with nice to reduce the impact of my intrusion. This
    helps a lot on my poor little SS1+ with only 16 MB, it was
    essential when I only had 8 MB.

  Casey Leedom (casey@gauss.llnl.gov) :
    [The X11 Server and the client are] competing for the same CPU as
    your server when you run it on the same machine.  Not really a
    major problem, except that the X11 client and the server are in
    absolute syncronicity and are context thrashing.

  Timothy H Panton (thp@westhawk.uucp) :
    Firstly it relies on the fact that most CPU's are mostly idle, X's
    cpu usage is bursty.  so the chances of you and your team-mate
    doing something cpu-intensive at the same time is small. If they
    are not then you get twice the cpu+memory available for your
    action.

    The second factor is that context switches are expensive, using 2
    cpu's halves them, you pay a price due to the overhead of going
    over the network, but this is offset in most cases by the improved
    buffering of a network (typically 20k vs 4k for a pipe), allowing
    even fewer context switches.

----------------------------
Other Sources of Information
----------------------------

  Adrian Nye (adrian@ora.com):
    A lot more tips on performance are in the paper "Improving X
    Application Performance" by Chris D. Peterson and Sharon Chang, in
    Issue 3 of The X Resource.

    An earlier version of this paper appeared in the Xhibition 1992
    conference proceedings.

    This paper is absolutely essential reading for X programmers.

  [Seems I've got some competition. :-)  --ed.]
  
--------------
Author & Notes
--------------
  This list is currently maintained by Art Mulder (art@cs.ualberta.ca)

  Suggestions, corrections, or submission for inclusion in this list
  are gladly accepted.  Layout suggestions and comments (spelling
  mistak's too! :-) are also welcome.

  Currently I have listed all contributors of the various comments and
  suggestions.  If you do not want to be credited, please tell me.

  speedup-x-faq is copyright (c) 1992 by Arthur E. Mulder

  You may copy this document in whole or in part as long as you don't
  try to make money off it, or pretend that you wrote it.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
 ...art mulder ( art@cs.ualberta.ca )    | "Do not be conformed to this world,
 Department of Computing Science         |  but be transformed by the renewal
 University of Alberta, Edmonton, Canada |  of your mind, ..."  Romans 12:2