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.
Reply-To: art@cs.ualberta.ca (Art Mulder)
Organization: University of Alberta, Edmonton, Canada
Date: Tue, 17 Nov 1992 20:16:49 GMT

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

- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
		    THIS LIST IS STILL VERY NEW.
		MORE SUGGESTIONS ARE EAGERLY SOUGHT.  
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -

	    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
  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 it's 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.
  It's focus, though, is on generally useful X information, and this
  FAQ is focussed on 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 also a subjective topic, and the individual users must
  balance speed versus features to come to a personal decision.
  Therefore this document will no doubt contain lots of 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. 

  Farrell McKay (fbm@ptcburp.ptcbu.oz.au) :
    I've used mwm, olwm, tvtwm, and twm.  Subjectively, I think twm is the
    fastest.  It seems to have the best performance to cost ratio, with a
    good feature set as well.

  Joe English (joe@trystero.art.com) :
    * Use twm or one of its variants instead of mwm.  It tends to
      be faster in almost every operation, except mapping pop-up
      windows and top-level shells.

    * Turn off nifty features like zooming, opaque move, etc.

    * Lay out your windows in a tiled fashion wherever possible.
      Not having to raise & lower windows (generating Expose events)
      when switching windows helps.

  I've found that a good font for tiling is
  -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 (anyone
  know the short form for this?).  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.  Specifically, 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) points out that on a Sun system, you should
  compile X 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 some 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 whole situation 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 it's 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 it's 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.

  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.

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

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

  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 that I've grown accustomed too, 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 the
    same site as above, 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 speed up how fast your pointer moves when you
  move your mouse.  This is very subjective to personal taste of
  course, but I like to be able to send my pointer across the screen
  with just a flick of the wrist.  I use "xset m 5 10", see the xset
  man page for further ideas & information.

  Hint: sometimes you may want to *slow down* your mouse tracking for
  fine work.  To cover my options, I placed a number of different mouse
  setting commands into menus in my window manager.
  eg: (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.

----------------------------
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                       Department of Computing Science \\
\\ art@cs.ualberta.ca          University of Alberta, Edmonton, Canada //
--
 ...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