From: art@cs.UAlberta.CA (Art Mulder)
Newsgroups: fj.mail-lists.x-window
Subject: comp.windows.x: Getting more performance out of X.  FAQ.
Date: 14 Oct 92 12:13:11 GMT
Distribution: fj
Organization: University of Alberta, Edmonton, Canada

Date: 13 Oct 92 22:19:10 GMT
Message-Id: <art.719014750@edwand>
Newsgroups: comp.windows.x

Archive-name: speedup-x-faq
Last-modified: 1992/10/13

- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -
	      THIS IS THE FIRST EDITION OF THIS LIST.  
	      MORE SUGGESTIONS ARE EAGERLY SOUGHT.  
- = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = -

		HOW TO MAXIMIZE THE PERFORMANCE OF X

  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. Fonts!
  4. The X11 Server
  5. About Clients:
  6. Programming Thoughts
  7. Say What!?
  8. 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. 

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.

  [ not sure about execution time.  Anyone? --ed.]

  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.

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

  [ Note: On my monochrome Sun ELC I've tried out XsunMono, but I
  really didn't notice any difference in speed from Xsun.  Can anyone
  provide any hard data on the difference between these two servers?
  --ed.]

  Also, make sure that your server was compiled with all possible
  optimization.

  Jeff Law (law@schirf.cs.utah.edu) :
    [On a Sun Sparc] Which compiler are you using?  You can get *very*
    large speedups in the server by switching from the 4.1.1 bundled
    compiler to gcc2 or the unbundled compiler.  [When compiling X] I'd
    bet $$$ that clients and libraries are smaller/faster, but that is
    much harder to measure.

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].  (Personally, I have a huge
    resource database; it doesn't seem to affect performance too badly,
    but your mileage may vary...)

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!  In my .xinitrc
  file, I now start up all my clients with commands like:
		( sleep 1; xbiff ) &
  --ed.]

About Clients:
--------------

  If you only have a few megabytes of Ram (I have 8) 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.

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

  [ Can anyone suggest alternatives that consume fewer resources?
  --ed.]

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

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, has anyone else
  tried it?  Comments?  --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                       Department of Computing Science \\
\\ art@cs.ualberta.ca          University of Alberta, Edmonton, Canada //