home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / x-faq / speedups < prev    next >
Encoding:
Internet Message Format  |  1998-10-11  |  36.1 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!boulder!csnews!nntpX.primenet.com!nntp.primenet.com!newspump.sol.net!newsfeed.direct.ca!cyclone.bc.net!rover.ucs.ualberta.ca!not-for-mail
  2. From: check.the.signature@nospam.ualberta.ca (Art Mulder)
  3. Newsgroups: comp.windows.x,news.answers,comp.answers
  4. Subject: comp.windows.x: Getting more performance out of X.  FAQ
  5. Supersedes: <x-perf_905155921@rockpile.ucs.ualberta.ca>
  6. Followup-To: poster
  7. Date: 5 Oct 1998 08:13:25 GMT
  8. Organization: University of Alberta, Edmonton, Canada
  9. Lines: 833
  10. Approved: news-answers-request@MIT.Edu
  11. Message-ID: <x-perf_907575121@rockpile.ucs.ualberta.ca>
  12. Reply-To: check.the.signature@nospam.ualberta.ca (Art Mulder)
  13. NNTP-Posting-Host: rockpile.ucs.ualberta.ca
  14. Summary: This posting contains a list of suggestions about what you
  15.     can do to get the best performance out of X on your
  16.     workstation -- without buying more hardware.
  17. Keywords: FAQ speed X
  18. Xref: senator-bedfellow.mit.edu comp.windows.x:125503 news.answers:141843 comp.answers:33420
  19.  
  20. Archive-name: x-faq/speedups
  21. Last-modified: 1998/09/10
  22. URL: http://www.ualberta.ca/~amulder/speedup-x-faq.txt
  23.  
  24. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  25.     HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting
  26. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  27.         Compiled by Art Mulder (art.mulder@ualberta.ca)
  28.  
  29.   More RAM, Faster CPU's, More disk space, Faster Ethernet....  These
  30.   are the standard responses you hear when you ask how to improve the
  31.   performance of your workstation.
  32.  
  33.   Well, more hardware isn't always an option, and I wonder if more
  34.   hardware is always even a necessity.
  35.  
  36.   This "FAQ" list is a collection of suggestions and ideas from
  37.   different people on the net on how you can the best possible
  38.   performance from X Windows on your workstation, WITHOUT PURCHASING
  39.   MORE HARDWARE.
  40.  
  41.   Performance is a highly subjective issue.  The individual user must
  42.   balance `speed' versus `features' in order to come to a personal
  43.   decision.  Therefore this document can be be expected to contain many
  44.   subjective opinions in and amongst the objective facts.
  45.  
  46.   This document is specifically concerned with X.  There are of course
  47.   many other factors that can affect the performance of a workstation.
  48.   However, they are outside the scope of this document.
  49.  
  50.     [ People seriously interested in the whole area of system
  51.     performance, might want to look at:
  52.     - "System Performance Tuning" by Mike Loukides.  (O'Reilly)
  53.     - "Configuration and Capacity Planning for Solaris Servers"
  54.     by Brian Wong (Prentice Hall)
  55.     - "Sun Performance and Tuning" by A.Cockcroft & R.Petit
  56.     (Prentice Hall)
  57.     Or various other books, too numerous to list here.  -ed]
  58.  
  59. -----------------
  60. Table of Contents
  61. -----------------
  62.   0. Introduction & Administrivia
  63.   1. Window Managers
  64.   2. The X Server
  65.        Which Server?
  66.        Locking the Server into RAM?
  67.        Starting your Server
  68.        Fonts
  69.        About the Resources File
  70.        Define Your Display Properly
  71.   3. Clients
  72.        A Better Clock for X
  73.        A Better Terminal Emulator for X
  74.        Other Client Comments
  75.        Tuning your client
  76.   4. Miscellaneous Suggestions
  77.        Pretty Pictures
  78.        A Quicker Mouse
  79.        Programming Thoughts
  80.        Backing Store
  81.        Say What!?
  82. *      Network Issues (TCP)
  83.   5. Other Sources of Information
  84.        The "Other X FAQ"
  85.        Books & etc.
  86.   6. Author & Notes
  87.   
  88. ! = changed since last issue.
  89. * = new since last issue.
  90.  
  91. -----------------------------
  92. Introduction & Administrivia
  93. -----------------------------
  94.  
  95.   This document is posted the first monday of each month, to the
  96.   Usenet news groups comp.windows.x, news.answers, and comp.answers.
  97.   If you are reading a copy of this FAQ which is more than a few
  98.   months old (see the "Last-modified" date above) you should probably
  99.   locate the latest edition, since the information may be outdated.
  100.  
  101.   If you do not know how to get those newsgroups and/or your site does
  102.   not receive them and/or this article has already expired, you can
  103.   retrieve this FAQ from an archive site.
  104.  
  105.   There exist several usenet FAQ archive sites.  To find out more about
  106.   them and how to access them, please see the "Introduction to the
  107.   *.answers newsgroups" posting in news.answers.
  108.  
  109.   The main FAQ archive is at rtfm.mit.edu.  This document can be found
  110.   there in /pub/usenet/news.answers/x-faq/speedups.  If you do not have
  111.   access to anonymous ftp, you can retrieve it by sending a mail
  112.   message to mail-server@rtfm.mit.edu with the command "send
  113.   usenet/news.answers/x-faq/speedups" in the message body.
  114.  
  115.   In addition, this FAQ is available at ftp.x.org (and its mirror
  116.   sites) in /contrib/faqs/speedup-x-faq.  Most X FAQs are there.
  117.  
  118. ---------------
  119. Window Managers
  120. ---------------
  121.  
  122.   There are a lot of window managers out there, with lots of different
  123.   features and abilities.  The choice of which to use is by necessity a
  124.   balancing act between performance and useful features.  Historically,
  125.   "twm" was considered to be a good candidate for a speedy window manager. 
  126.  
  127.   A couple of generic tricks you can try to soup up your window manger,
  128.   is turning off unnecessary things like "zooming" and "opaque move".
  129.   Also, if you lay out your windows in a tiled manner, you reduce the
  130.   amount of cpu power spent in raising and lowering overlapping
  131.   windows.                           Joe English (joe@trystero.art.com)
  132.  
  133.   I've found that a good font for tiling is 7x13 (aka:
  134.   -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 ). It is
  135.   the biggest font I know of that I can use on my Sun (1152x900 screen)
  136.   and still get two 80 column terminal windows side-by-side on the
  137.   display with no overlap.  Other font suggestions will be accepted.
  138.  
  139. Suggestions for your consideration:
  140.  
  141.   I used to recommend fvwm here, but the 2.x man page for fvwm
  142.   now says: "Although it was redesigned to minimize memory consumption,
  143.   it is now as bloated as any other window-manager. Users searching for
  144.   a low-memory consumption window-manager are advised to look elsewhere,
  145.   possibly to an earlier version of fvwm."
  146.         [thanks to: Ian Thurlbeck (ian@stams.strath.ac.uk) ]
  147.  
  148.   You might want to investigate the "Lightweight Window Manager"
  149.   by Elliott Hughes.  http://users.ch.genedata.com/~enh
  150.   It's reported to be quite spartan.  
  151.         [thanks to: rjarvine@sitriini.hut.fi]
  152.  
  153. ------------ 
  154. The X Server
  155. ------------
  156.  
  157. Which Server?
  158. - - - - - - -
  159.   Make sure that your server is a proper match for your hardware.
  160.   If you have a monochrome monitor, use a monochrome X11 server.
  161.  
  162.   On my Monochrome Sun, I haven't noticed much difference between
  163.   the Xsun (colour) server and XsunMono, however it was pointed out to
  164.   me that XsunMono is about 800k smaller and therefore should contribute
  165.   to less paging.  
  166.          [ thanks to: Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk),
  167.                         Michael Salmon (Michael.Salmon@eos.ericsson.se) ]
  168.  
  169.   How your server was compiled can also make a difference.  Jeff Law
  170.   (law@schirf.cs.utah.edu) advises us that on a Sun system, X should be
  171.   compiled with gcc (version 2.*) or with the unbundled Sun compiler.
  172.   You can expect to get "*very* large speedups in the server" by not
  173.   using the bundled SunOS compiler.  I assume that similar results
  174.   would occur if you used one of the other high-quality commercial
  175.   compilers on the market.
  176.  
  177.   Ben Jackson (bjj@sequent.com):
  178.     The XFree86 XF86_SVGA server that comes with the binary
  179.     distributions has support for 17 different kinds of SVGA hardware.
  180.     On any single machine installation, support for all but one can be
  181.     removed, drastically reducing the size of the server binary.  This
  182.     is accomplished by installing the LinkKit distribution (available
  183.     from ftp.xfree86.org, or the mirror site where you got the rest of
  184.     the tarballs) and editing the included `site.def' definition of
  185.     XF86SvgaDrivers.  More details are included in the README (installs
  186.     as /usr/X11R6/lib/Server/README).  On my FreeBSD 2.0.5 machine, the
  187.     stock XF86_SVGA is 2.7M.  A cirrus-only version is 1.5M, and took
  188.     less than 5 minutes to build.
  189.  
  190.  
  191. Locking the Server into RAM?
  192. - - - - - - - - - - - - - - -
  193.   It was suggested that perhaps hacking the X server so that it would
  194.   stay locked in RAM (and therefore not get paged out) might help
  195.   performances.  eg: via a call to plock().
  196.        [Eric C Claeys (ecc@eperm.att.com), Danny Backx (db@sunbim.be),
  197.     Juan D. Martin (juando@cnm.us.es)]
  198.  
  199.   Kenny Ranerup [kenny@axis.se] tried this a few years ago and
  200.   confirmed that it does work, and can give a noticeable speedup.  But,
  201.   you must be careful that your server doesn't grow too large (ie,
  202.   close to the size of your RAM).  He also makes the point that slow
  203.   interactive performace is in many cases due to client paging (paging
  204.   in libraries), and not server paging.
  205.  
  206. Starting your Server
  207. - - - - - - - - - - -
  208.   Joe English (joe@trystero.art.com) :
  209.     If you start up a lot of clients in your .xsession or whatever, sleep
  210.     for a second or two after launching each one.  After I changed my
  211.     .xclients script to do this, logging in actually took *less* time...
  212.     we have a heavily loaded system without much core, though.
  213.  
  214.   This sounds crazy, but I have confirmed that it works!  
  215.  
  216.   Warner Losh (imp@boulder.openware.com) provided me with a good
  217.   explanation of why this works, which I have summarized here:
  218.  
  219.     When you start up an X server it takes a huge amount of time to
  220.     start accepting connections.  A lot of initialization is done by
  221.     the server when it starts.  This process touches a large number of
  222.     pages.  Any other process running at the same time would fight the
  223.     server for use of the CPU, and more importantly, memory.  If you
  224.     put a sleep in there, you give the Server a chance to get itself
  225.     sorted out before the clients start up.
  226.  
  227.     Similarly, there is also a lot of initialization whenever an X
  228.     client program starts: toolkits registering widgets, resources
  229.     being fetched, programs initializing state and "databases" and so
  230.     forth.  All this activity is typically memory intensive.  Once this
  231.     initialization is done ("The process has reached a steady state"),
  232.     the memory usage typically settles down to using only a few pages.
  233.     By using sleeps to stagger the launching of your clients in your
  234.     .Xinitrc , you avoid them fighting each other for your
  235.     workstation's limited resources
  236.  
  237.   This is most definitely a "Your Mileage May Vary" situation, as there
  238.   are so many variables to be considered: available RAM, local swap
  239.   space, load average, number of users on your system, which clients
  240.   you are starting, etc.
  241.  
  242.   Currently in my .xinitrc I have a situation like:
  243.     (sleep 1; exec xclock ) &
  244.     (sleep 1; exec xbiff ) &
  245.     (sleep 1; exec xterm ) &
  246.     (sleep 1; exec xterm ) &
  247.  
  248.   I've experimented with:
  249.     (sleep 1; exec xclock ) &
  250.     (sleep 2; exec xbiff ) &
  251.     (sleep 3; exec xterm ) &
  252.     (sleep 4; exec xterm ) &
  253.  
  254.   I've even tried:
  255.     (sleep 2; exec start_X_clients_script ) &
  256.   and then in start_X_clients_script I had:
  257.     (sleep 1; exec xclock ) &
  258.     (sleep 1; exec xbiff ) &
  259.     (sleep 1; exec xterm ) &
  260.     (sleep 1; exec xterm ) &
  261.  
  262.     [ The idea with this last one was to make sure that xinit had
  263.     completely finished processing my .xinitrc, and had settled down
  264.     into a "steady state" before the sleep expired and all my clients
  265.     were launched. ]
  266.  
  267.   All of these yielded fairly comparable results, and so I just stuck
  268.   with my current setup, for its simplicity.  You will probably have to
  269.   experiment a bit to find a setup which suits you.
  270.  
  271.   Theo Honohan <th208@cam.ac.uk> suggests that you might
  272.   want to investigate 'xtoolwait'  (which can be found at
  273.   ftp.x.org/contrib/utilities/xtoolwait-1.1.tar.gz) which does
  274.   similar pacing of X startup.
  275.  
  276. Fonts
  277. - - -
  278.   Loading fonts takes time and RAM.  If you minimize the number of fonts
  279.   your applications use, you'll get speed increases in load-up time.
  280.  
  281.   One simple strategy is to choose a small number of fonts (one small,
  282.   one large, one roman, whatever suits you) and configure all your
  283.   clients -- or at least all your heavily used clients -- to use only
  284.   those few fonts.  Client programs should start up quicker if their
  285.   font is already loaded into the server.  This will also conserve
  286.   server resources, since fewer fonts will be loaded by the server.
  287.                   [ Farrell McKay (fbm@ptcburp.ptcbu.oz.au),
  288.                     Joe English (joe@trystero.art.com) ]
  289.  
  290.   eg: My main xterm font is 7x13, so I also have twm set up to use 7x13
  291.   in all its menus and icons etc.  Twm's default font is 8x13.  Since
  292.   I don't normally use 8x13, I've eliminated one font from my server.
  293.  
  294.   Oliver Jones (oj@roadrunner.pictel.com):
  295.     Keep fonts local to the workstation, rather than loading them over nfs.
  296.     If you will make extensive use of R5 scalable fonts, use a font server.
  297.  
  298.   Anthony Stuckey (astuckey@predator.urbana.mcd.mot.com):
  299.     This is particularly good advice on Linux.  Linux has a problem
  300.     with non-floating-point capable hardware (486SX's, etc) in that
  301.     they will freeze for up to a few minutes while the Scalable fonts
  302.     are created... The font server fixes this to a certain extent, as
  303.     does removing the scalable fonts from your font path. ... I believe
  304.     that a writeup of this problem is in the Linux Tips FAQ
  305.  
  306.     [The main point here is that non-fpu machines, linux or otherwise,
  307.     should experience a benefit from running a font server.]
  308.  
  309. About the Resources File
  310. - - - - - - - - - - - - -
  311.  
  312.     Keep your .Xresources / .Xdefaults file small.  Saves RAM and saves
  313.     on server startup time.          Joe English (joe@trystero.art.com)
  314.  
  315.   One suggestion:
  316.  
  317.     In your .Xresources file, try putting only the minimum number of
  318.     resources that you want to have available to all of your
  319.     applications.  For example:  *reverseVideo: true
  320.  
  321.     Then, separate your resources into individual client-specific
  322.     resource files.  For example: $HOME/lib/app-defaults.  In your
  323.     .login file set the environment variable XUSERFILESEARCHPATH:
  324.  
  325.     setenv XUSERFILESEARCHPATH $HOME/lib/app-defaults/%N
  326.  
  327.     (Note:  It is easier and quicker for Xt to process
  328.     XUSERFILESEARCHPATH than XAPPLRESDIR.)
  329.  
  330.     [ The "comp.windows.x Frequently Asked Questions" FAQ contains
  331.     an excellent explanation of how this and the other main X
  332.     environment variables work.  --ed.]
  333.  
  334.     So, when xterm launches, it loads (through Xt) its resources from
  335.     .../app-defaults/XTerm.  Xdvi finds them in .../app-defaults/XDvi,
  336.     and so on and so forth.  Note that not all clients follow the same
  337.     XXxxx resource-file naming pattern.  You can check in your system
  338.     app-defaults directory (often: /usr/X11R5/lib/X11/app-defaults/) to
  339.     find the proper name, and then name your personal resource files
  340.     with the same name.
  341.  
  342.     This is all documented in the Xt Specification (pg 125 & 666).
  343.             [Thanks to: Kevin Samborn (samborn@mtkgc.com),
  344.                  Michael Urban (urban@cobra.jpl.nasa.gov),
  345.              Tom Bagli (tomb@gator.bocaraton.ibm.com),
  346.                      and Mike Long (mikel@ee.cornell.edu).
  347.          Kevin is willing mail his setup files to inquirers.]
  348.  
  349.   This method of organizing your personal resources has the following
  350.   benefits:
  351.  
  352.     - Easier to maintain / more usable.
  353.  
  354.     - Fewer resources are stored in the X server in the RESOURCE_MANAGER
  355.       property.  As a side benefit your server may start fractionally
  356.       quicker, since it doesn`t have to load all your resources.
  357.  
  358.     - Applications only process their own resources, never have to sort
  359.       through all of your resources to find the ones that affect them.
  360.  
  361.   It also has drawbacks:
  362.  
  363.     - the application that you are interested in has to load an
  364.       additional file every time it starts up.  This doesn't seem to
  365.       make that much of a performance difference, and you might
  366.       consider this a huge boon to usability.  If you are modifying an
  367.       application's resource database, you just need to re-run the
  368.       application without having to "xrdb" again.
  369.  
  370.     - xrdb will by default run your .Xresources file through cpp.  When
  371.       your resources are split out into multiple resource files and
  372.       then loaded by the individual client programs, they will not.
  373.       WATCH OUT FOR THIS!!
  374.  
  375.       I had C style comments in my .Xresources file, which cpp stripped
  376.       out.  When I switched to this method of distributed resource
  377.       files I spent several frustrating days trying to figure out why
  378.       my clients were not finding their resources.  Xt did *NOT*
  379.       provide any error message when it encountered the C style
  380.       comments in the resource files, it simply, silently, aborted
  381.       processing the resource file.
  382.  
  383.       The loss of preprocessing (which can be very handy, e.g. ``#ifdef
  384.       COLOR'' ...) is enough to cause some people to dismiss this
  385.       method of resource management.
  386.  
  387.     - You may also run into some clients which "break the rules".  For
  388.       example, neither Emacs (18.58.3) nor Xvt (1.0) will find their
  389.       resources if they are anywhere other than in .Xresources.
  390.  
  391.       This is because emacs (and presumably, Xvt) are not Xt based
  392.       applications.  They are coded to use Xlib directly.
  393.       XUSERFILESEARCHPATH and XAPPLRESDIR are Xt features.
  394.                  Larry Williamson (larry@witch.mitra.com)
  395.  
  396.     - when starting up a client on a machine that does not share files
  397.       with the machine where your resources are stored, your client
  398.       will not find its resources.  Loading all your resources into the
  399.       server will guarantee that all of your clients will always find
  400.       their resources.            Casey Leedom (casey@gauss.llnl.gov)
  401.  
  402.   A possible compromise that I have tried, is to put resources for all
  403.   my heavily used clients (eg: xterm) into my .Xresources file, and to
  404.   use the "separate resources files" method for clients that I seldom
  405.   use.
  406.  
  407. Define Your Display Properly
  408. - - - - - - - - - - - - - - -
  409.  
  410.   Client programs are often executed on the same machine as the
  411.   server.  In that situation, rather than setting your DISPLAY
  412.   environment variable to "<hostname>:0.0", where <hostname> is the
  413.   name of your workstation, you should set your DISPLAY variable to
  414.   "unix:0.0" or ":0.0".  By doing this you access optimized routines
  415.   that know that the server is on the same machine and use a shared
  416.   memory method of transferring requests.
  417.             [thanks to Patrick J Horgan (pjh70@ras.amdahl.com)]
  418.  
  419.   See the _DISPLAY NAMES_ section of the X(1) man page for further
  420.   explanation of how to properly set your display name.
  421.  
  422.   "I don't think it's stock MIT, but (at least) Data General and HP
  423.   have libraries that are smart enough to use local communication even
  424.   when the DISPLAY isn't set specially."
  425.                   Rob Sartin (88opensi!sartin@uunet.UU.NET)
  426.  
  427.   [Jody Goldberg (jody@algorithmics.com) sent me an Xlib patch to
  428.   change stock R5 to use local communication even if DISPLAY is not
  429.   properly set.  I don't want to get in the business of distributing or
  430.   trying to juggle non-MIT patches and so have elected not to include
  431.   it here.  Hopefully MIT will apply this minor (~8 lines) patch
  432.   themselves.  In the meantime, if you want to try it yourself, email
  433.   Jody.  --ed.]
  434.  
  435. -------
  436. Clients
  437. -------
  438.  
  439.   If you only have a few megabytes of Ram then you should think
  440.   carefully about the number of programs you are running.  Think also
  441.   about the _kind_ of programs you are running.  For example:  Is there
  442.   a smaller clock program than xclock?
  443.  
  444.   Unfortunately, I haven't really noticed that programs advertise how
  445.   large they are, so the onus is on us to do the research and spread
  446.   the word.
  447.  
  448.   [ Suggestions on better alternatives to the some of the standard
  449.   clients (eg: Xclock, Xterm, Xbiff) are welcome.  --ed.]
  450.  
  451.   I've received some contradictory advice from people, on the subject
  452.   of X client programs.  Some advocate the use of programs that are
  453.   strictly Xlib based, since Xt, Xaw and other toolkits are rather
  454.   large.  Others warn us that other applications which you are using
  455.   may have already loaded up one or more of these shared libraries.  In
  456.   this case, using a non-Xt (for example) client program may actually
  457.   _increase_ the amount of RAM consumed.
  458.  
  459.   The upshot of all this seems to be: Don't mix toolkits.  That is, try
  460.   and use just Athena clients, or just Xview clients (or just Motif
  461.   clients, etc).  If you use more than one, then you're dragging in
  462.   more than one toolkit library.
  463.  
  464.   Know your environment, and think carefully about which client
  465.   programs would work best together in that environment.
  466.  
  467.         [Thanks to: Rob Sartin (88opensi!sartin@uunet.UU.NET),
  468.     Duncan Sinclair (sinclair@dcs.gla.ac.uk | sinclair@uk.ac.gla.dcs) ]
  469.  
  470. A Better Clock for X
  471. - - - - - - - - - - -
  472.  
  473. 1) xcuckoo
  474.    suggested by: Duncan Sinclair (sinclair@dcs.gla.ac.uk)
  475.    available: on export.lcs.mit.edu
  476.  
  477.    Xcuckoo displays a clock in the title bar of *another* program.
  478.    Saves screen real estate.
  479.  
  480. 2) Swisswatch
  481.    suggested by: Theo Honohan <th208@cam.ac.uk
  482.    ftp://sunsite.doc.ic.ac.uk/packages/X11/R5contrib/swisswatch-0.06.tar.Z
  483.  
  484.  
  485.   Of course, the ultimate clock --- one that consumes no resources, and 
  486.   takes up no screen real estate --- is the one that hangs on your wall.
  487.   :-) 
  488.  
  489. A Better Terminal Emulator for X
  490. - - - - - - - - - - - - - - - - -
  491.  
  492.   From the README file distributed with xterm:
  493.  
  494.   +-----
  495.   |         Abandon All Hope, Ye Who Enter Here
  496.   |
  497.   | This is undoubtedly the most ugly program in the distribution.
  498.   | ...
  499.   +-----
  500.  
  501.   Ugly maybe, but at my site it's still the most used.  I suspect that
  502.   xterm is one of the most used clients at many, if not most sites.
  503.   Laziness?  Isn't there a better terminal emulator available?  See
  504.   below.
  505.  
  506.   If you must use xterm, you can try reducing the number of saveLines
  507.   to reduce memory usage.  [ Oliver Jones (oj@roadrunner.pictel.com),
  508.            Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk) ]
  509.  
  510. 1) Xvt
  511.    Suggested by: Richard Hesketh (rlh2@ukc.ac.uk)
  512.    Author: John D. Bovey (jdb@ukc.ac.uk)
  513.    Available: http://unix.hensa.ac.uk/pub/misc/unix/xvt
  514.  
  515.    [From the README file] "Xvt is an X terminal-emulator that is
  516.    designed to be more or less compatible with xterm while using much
  517.    less swap space.  It is mainly intended for use at sites which use
  518.    large numbers of X terminals but may also be useful on single
  519.    workstations that are short of memory.  On a [SunOS 4.1.* Sparc], an
  520.    initially invoked xvt uses about 1/3 megabyte of swap while xterm
  521.    uses about 1.3 megabytes (obtained by running pstat rather than ps
  522.    which seems to give unreliable size figures on SPARCs).  The main
  523.    way that xvt achieves its small size is by avoiding the use of the X
  524.    toolkit."
  525.  
  526.    There have been some conflicting opinions aired over xvt vs. xterm.
  527.    Different sites with different needs will likely have to do
  528.    their own evaluation.  Caveat Emptor, your mileage may vary.
  529.  
  530. 2) rxvt
  531.    Available: http://babayaga.math.fu-berlin.de:80/~rxvt/
  532.      
  533.    Originally a stripped down Linux port of xvt, with some 
  534.    minor modifications, it's now being actively developed
  535.    on it's own.
  536.     [thanks to: Theo Honohan <th208@cam.ac.uk for the update]
  537.  
  538.  
  539. Other Client Comments
  540. - - - - - - - - - - -
  541.   When using the xlock screen locking client, the "qix" mode is
  542.   much more lightweight than the default mode.  
  543.                  [Q. Alex Zhao (azhao@cc.gatech.edu)]
  544.  
  545.   I can confirm the previous report from personal experience  here.  In
  546.   a lab full of ~20 sun 3/80's all running the Xkernel software, the
  547.   subnet was getting regularly clobbered.  This was tracked down to
  548.   students running xlock.  Since these machines are all xterminals, the
  549.   actual xlock program runs remotely, and generates a scary amount of
  550.   network traffic to draw the default 'swarm' pictures on the screen.
  551.   We have removed this program and replaced it with a much simpler
  552.   screen locking program which simply blanks the screen.        [ed.]
  553.  
  554.   A suggestion: xtrlock, by Ian Jackson (ijackson@nyx.cs.du.edu)
  555.   It is very small (about 16k running), and doesn't produce any traffic
  556.   while locked. Drawback: It doesn't make your screen invisible.
  557.               [ Klamer Schutte (klamer@ph.tn.tudelft.nl) ]
  558.  
  559.   An improved xbiff: Xbuffy.  It can watch multiple mailboxes and can
  560.   do a pop up showing the From and Subject line of incoming mail.
  561.   Xbiff doesn't eat much memory and Xbuffy tends to be about the same
  562.   (on the RS/6000, xbuffy tends use just a little less memory).  It is
  563.   in the contrib directory on ftp.x.org.
  564.                                [ Bill Pemberton (wfp5p@virginia.edu) ]
  565.  
  566. Tuning your client
  567. - - - - - - - - - -
  568.  
  569.   Suggestions on how you can tune your client programs to work faster.
  570.  
  571.   From Scott Barman (scott@asd.com) comes a suggestion regarding Motif
  572.   Text Field Widgets:
  573.  
  574.     I noticed that during data entry into Motif text field widgets, I
  575.     was getting a slight lag in response to some keystrokes,
  576.     particularly the initial one in the field.  Examining the what was
  577.     going on with xscope I found it.  It seems that when the resource
  578.     XmNblinkRate is non-zero and the focus is on a text field widget
  579.     (or even just a text widget) the I-beam cursor will blink.  Every
  580.     time the cursor appears or disappears in those widgets, the widget
  581.     code is making a request to the server (CopyArea).  The user can
  582.     stop this by setting the resource XmNblinkRate to 0.  It is not
  583.     noticeable on a 40MHz SPARC, but it does make a little difference
  584.     on a [slower system].
  585.  
  586.   This specific suggestion can probably be applied in general to lots
  587.   of areas.  Consider your heavily used clients, are there any minor
  588.   embellishments that can be turned off and thereby save on Server
  589.   requests?
  590.  
  591. -------------------------
  592. Miscellaneous Suggestions
  593. -------------------------
  594.  
  595. Pretty Pictures
  596. - - - - - - - -
  597.   Don't use large bitmaps (GIF's, etc) as root window backgrounds.
  598.  
  599.   - The more complicated your root window bitmap, the slower the server
  600.     is at redrawing your screen when you reposition windows (or redraw,
  601.     etc)
  602.  
  603.   - These take up RAM, and CPU power.  I work on a Sun SPARC and I'm
  604.     conscious of performance issues, I can't comprehend it when I see
  605.     people with a 4mb Sun 3/60 running xphoon as their root window.
  606.  
  607.     I'll let someone else figure out how much RAM would be occupied by
  608.     having a full screen root image on a colour workstation.
  609.  
  610.   - If you're anything like me, you need all the screen real estate
  611.     that you can get for clients, and so rarely see the root window
  612.     anyway.
  613.  
  614.               [ Thanks to Qiang Alex Zhao (azhao@cs.arizona.edu) 
  615.             for reminding me of this one. --ed.]
  616.  
  617. A Quicker Mouse
  618. - - - - - - - -
  619.   Using xset, you can adjust how fast your pointer moves on the screen
  620.   when you move your mouse.  I use "xset m 3 10" in my .xinitrc file,
  621.   which lets me send my pointer across the screen with just a flick of
  622.   the wrist.  See the xset man page for further ideas and information.
  623.  
  624.   Hint: sometimes you may want to *slow down* your mouse tracking for
  625.   fine work.  To cover my options, I have placed a number of different
  626.   mouse setting commands into a menu in my window manager.  
  627.  
  628.   e.g. (for twm) :
  629.       menu "mouse settings" {
  630.         "Mouse Settings:"            f.title
  631.     "  Very Fast"                ! "xset m 7 10 &"
  632.     "  Normal (Fast)"            ! "xset m 3 10 &"
  633.     "  System Default (Un-Accelerated)"    ! "xset m default &"
  634.     "  Glacial"                ! "xset m 0 10 &"
  635.       }
  636.  
  637. Programming Thoughts
  638. - - - - - - - - - - -
  639.   Joe English (joe@trystero.art.com) :
  640.     To speed up applications that you're developing, there are tons of
  641.     things you can do.  Some that stick out:
  642.  
  643.     - For Motif programs, don't set XmFontList resources for individual
  644.       buttons, labels, lists, et. al.; use the defaultFontList or
  645.       labelFontList or whatever resource of the highest-level manager
  646.       widget.  Again, stick to as few fonts as possible.
  647.  
  648.     - Better yet, don't use Motif at all.  It's an absolute pig.
  649.  
  650.     - Don't create and destroy widgets on the fly.  Try to reuse them.
  651.       (This will avoid many problems with buggy toolkits, too.)
  652.  
  653.     - Use a line width of 0 in GCs.  On some servers this makes a HUGE
  654.       difference.
  655.  
  656.     - Compress and collapse multiple Expose events.  This can make the
  657.       difference between a fast application and a completely unusable
  658.       one.
  659.  
  660.   Francois Staes (frans@kiwi.uia.ac.be) :
  661.     Just a small remark: I once heard that using a better malloc
  662.     function would greatly increase performance of Xt based
  663.     applications since they use malloc heavily. They suggested trying
  664.     out the GNUY malloc, but I didn't find the time yet. I did some
  665.     tests on small programs just doing malloc and free, and the
  666.     differences were indeed very noticeable ( somewhat 5 times faster)
  667.  
  668.   [ Any confirmation on this from anyone?  --ed.]
  669.  
  670.   Andre' Beck (Andre_Beck@IRS.Inf.TU-Dresden.de) :
  671.  
  672.   - Unnecessary NoExpose Events.
  673.  
  674.     Most people use XCopyArea/XCopyPlane as fastest blit routines, but
  675.     they forget to reset graphics_exposures in the GC used for the
  676.     blits. This will cause a NoExpose Event every blit, that, in most
  677.     cases, only puts load onto the connection and forces the client to
  678.     run through its event-loop again and again.
  679.  
  680.   - Thousands of XChangeGC requests.
  681.  
  682.     This "Gfx Context Switching" is also seen in most handcoded X-Apps,
  683.     where only one or few GCs are created and then heavily changed
  684.     again and again.  Xt uses a definitely better mechanism, by caching
  685.     and sharing a lot of GCs with all needed parameters. This will
  686.     remove the load of subsequent XChangeGC requests from the
  687.     connection (by moving it toward the client startup phase).
  688.  
  689. Backing Store
  690. - - - - - - -
  691.  Joe Nardelli (nardelli@mitre.org) :
  692.    I've found that using 'backing store' really speeds up redrawing of
  693.    complex windows.  Ex: I have a window that stores an intricate 3-D
  694.    sceen, and redrawing it every time a window pops up in front is a
  695.    real waste of time.  It is much quicker to set the 'backing store'
  696.    attribute to either 'Always' or 'WhenMapped'. ...  Note that the
  697.    server keeps a copy of the window in memory, so very simple windows
  698.    may actually slow some systems done.  Your mileage may vary.
  699.  
  700.  Here is another way of looking at the issue of backing store.
  701.  If you are low on memory, you should disable backing store, since a
  702.  redraw will be quicker than pulling the saved image from swap space.
  703.  (We are assuming here that you are sufficiently low on memory that
  704.  your backing store ends up in swap space)  If you have enough memory,
  705.  backing store will beat redraw all the time -- unless you have _very_
  706.  fast hardware.
  707.         [from discussions with Nicolai Langfeldt (janl@ifi.uio.no) ]
  708.  
  709. Say What!?
  710. - - - - - - 
  711.   Some contributors proposed ideas that seem right off the wall at first:
  712.  
  713.   David B. Lewis (by day: dbl@osf.org, by night: david%craft@uunet.uu.net) :
  714.     How about this: swap displays with someone else. Run all your
  715.     programs on the other machine and display locally; the other user
  716.     runs off your machine onto the other display. Goal: reduce context
  717.     switches in the same operation between client and server.
  718.  
  719.   I'm not in a situation where I can easily try this, but I have
  720.   received the following confirmation...
  721.  
  722.   Michael Salmon (Michael.Salmon@eos.ericsson.se):
  723.     I regularly run programs on other machines and I notice a big
  724.     difference. I try to run on a machine where I will reduce net usage
  725.     and usually with nice to reduce the impact of my intrusion. This
  726.     helps a lot on my poor little SS1+ with only 16 MB, it was
  727.     essential when I only had 8 MB.
  728.  
  729.   Casey Leedom (casey@gauss.llnl.gov) :
  730.     [The X11 Server and the client are] competing for the same CPU as
  731.     your server when you run it on the same machine.  Not really a
  732.     major problem, except that the X11 client and the server are in
  733.     absolute synchronicity and are context thrashing.
  734.  
  735.   Timothy H Panton (thp@westhawk.uucp) :
  736.     Firstly it relies on the fact that most CPU's are mostly idle, X's
  737.     cpu usage is bursty.  so the chances of you and your teammate
  738.     doing something cpu-intensive at the same time is small. If they
  739.     are not then you get twice the cpu+memory available for your
  740.     action.
  741.  
  742.     The second factor is that context switches are expensive, using 2
  743.     cpu's halves them, you pay a price due to the overhead of going
  744.     over the network, but this is offset in most cases by the improved
  745.     buffering of a network (typically 20k vs 4k for a pipe), allowing
  746.     even fewer context switches.
  747.  
  748. Network Issues (TCP)
  749. - - - - - - - - - - -
  750.  
  751.   It is questionable whether the following belongs in this FAQ, since
  752.   it seems to mostly be a question of network performances.  But here
  753.   it is:
  754.  
  755.   Bob Arendt (rdarendt@mcmail.com) :
  756.  
  757.     It turns out that matching TCP sendspace and recvspace on client
  758.     and server can dramatically affect performance.  Sun/UNIX and
  759.     TCPware/VMS default to 4Kbyte buffer sizes (out-of-the-box).
  760.     Ultrix/DEC and DigitalUnix/DEC default to 32Kbyte buffer sizes.
  761.     Using the same workstation hardware and FDDI network connections
  762.     I got the following stats:
  763.  
  764.     x11perf -putImage100  (run on TCPware/VMS client, default 4K)
  765.      = 4.5 msec  with TCPware/VMS server, default 4K
  766.      = 600 msec  with Ultrix/VMS server, default 32K
  767.       = 600 msec  with DigitalUnix server, default 32k
  768.  
  769.     Changing the Ultrix config and DigitalUnix kernal to 4K TCP
  770.     send/recv sizes resulted in matching speeds of 4.5 msec.  In this
  771.     case, less was more :-)
  772.  
  773.     X11 must use system TCP default buffer settings.  With a
  774.     mismatched, large recvs pace, it appears that polling mechanism
  775.     (ala select()?)  empties the buffers rather than triggering on
  776.     buffer-full.  Matching to small buffers is probably better than
  777.     larger buffers since it tends to reduce latency and most network
  778.     devices break up traffic into smaller chunks anyway.
  779.  
  780.     This also appears to be an issue for Windows/X11 servers.
  781.     Running windowsNT on the same Dec Alpha with a third-party X11
  782.     server I see the same dismal response times.  I suspect it's the
  783.     same problem (in conjuncution with X11->winDoze translation delay).
  784.     Don't know how to tune windowsNT though.
  785.  
  786.  
  787. ----------------------------
  788. Other Sources of Information
  789. ----------------------------
  790.  
  791. The "Other X FAQ"
  792. - - - - - - - - -
  793.  
  794.   David B. Lewis (faq%craft@uunet.uu.net) maintains the informative and
  795.   well written "comp.windows.x Frequently Asked Questions" document.
  796.   Its focus is on general X information, while this FAQ concentrates
  797.   on performance.
  798.  
  799.   The comp.windows.x FAQ does address the issue of speed, but only with
  800.   regards to the X server.  The gist of that topic seems to be:
  801.     "Use X11R5, it is faster than R4".
  802.   (Please see the X FAQ for complete details).
  803.  
  804. Books & etc.
  805. - - - - - - -
  806.  
  807.   Volume 8 in O'Reilly's X Window System Series; ``X Window System
  808.   Administrator's Guide'' is a book that all X administrator's should
  809.   read.  (email your snailmail address to catalog@ora.com for a catalog)
  810.  
  811.   Adrian Nye (adrian@ora.com):
  812.     A lot more tips on performance are in the paper "Improving X
  813.     Application Performance" by Chris D. Peterson and Sharon Chang, in
  814.     Issue 3 of The X Resource.
  815.  
  816.     An earlier version of this paper appeared in the Xhibition 1992
  817.     conference proceedings.
  818.  
  819.     This paper is absolutely essential reading for X programmers.
  820.   [For information on The X Resource, contact paula@ora.com --ed.]
  821.  
  822.   Sajee Mathew (scm@cdssua.chesapeake.com)
  823.     "Motif Debugging and Performance Tuning" by Doug Young, Prentice
  824.     Hall, 1994.  Good book.  The section on performance tuning presents
  825.     some useful techniques for speeding up X programs from the X-lib
  826.     and toolkit levels.
  827.  
  828. --------------
  829. Author & Notes
  830. --------------
  831.   This list is currently maintained by Art Mulder (art.mulder @ ualberta.ca)
  832.  
  833.   Suggestions, corrections, or submission for inclusion in this list
  834.   are gladly accepted.  Layout suggestions and comments (spelling
  835.   mistak's too! :-) are also welcome.
  836.  
  837.   Currently I have listed all contributors of the various comments and
  838.   suggestions.  If you do not want to be credited, please tell me.
  839.  
  840.   speedup-x-faq is copyright (c) 1993-96 by Arthur E. Mulder
  841.  
  842.   You may copy this document in whole or in part as long as you don't
  843.   try to make money off it, or pretend that you wrote it.
  844.  
  845. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  846. PLEASE NOTE: The reply address in the headers is bogus.  I regret this
  847. action, but it is necessary to ATTEMPT to defeat Junk Email robots. 
  848.  
  849. -- 
  850. ...art mulder ( art.mulder@ualberta.ca )( http://www.ualberta.ca/~amulder/ )
  851.               ( Sys Admin / Support Analyst, Network Resources )
  852.               ( Computing and Network Services, U of Alberta, Edmonton )
  853.