|
|
| Home > Operational Systems > x-faq > |
comp.windows.x: Getting more performance out of X. FAQ |
Archive-name: x-faq/speedups
Last-modified: 1998/09/10
URL: http://www.ualberta.ca/~amulder/speedup-x-faq.txt
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Compiled by Art Mulder (art.mulder@ualberta.ca)
More RAM, Faster CPU's, More disk space, Faster Ethernet.... These
are the standard responses you hear when you ask how to improve the
performance of your workstation.
Well, more hardware isn't always an option, and I wonder if more
hardware is 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 X Windows on your workstation, WITHOUT PURCHASING
MORE HARDWARE.
Performance is a highly 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.
This document is specifically concerned with X. There are of course
many other factors that can affect the performance of a workstation.
However, they are outside the scope of this document.
[ People seriously interested in the whole area of system
performance, might want to look at:
- "System Performance Tuning" by Mike Loukides. (O'Reilly)
- "Configuration and Capacity Planning for Solaris Servers"
by Brian Wong (Prentice Hall)
- "Sun Performance and Tuning" by A.Cockcroft & R.Petit
(Prentice Hall)
Or various other books, too numerous to list here. -ed]
-----------------
Table of Contents
-----------------
0. Introduction & Administrivia
1. Window Managers
2. The X Server
Which Server?
Locking the Server into RAM?
Starting your Server
Fonts
About the Resources File
Define Your Display Properly
3. Clients
A Better Clock for X
A Better Terminal Emulator for X
Other Client Comments
Tuning your client
4. Miscellaneous Suggestions
Pretty Pictures
A Quicker Mouse
Programming Thoughts
Backing Store
Say What!?
* Network Issues (TCP)
5. Other Sources of Information
The "Other X FAQ"
Books & etc.
6. Author & Notes
! = changed since last issue.
* = new since last issue.
-----------------------------
Introduction & Administrivia
-----------------------------
This document is posted the first monday of each month, to the
Usenet news groups comp.windows.x, news.answers, and comp.answers.
If you are reading a copy of this FAQ which is more than a few
months old (see the "Last-modified" date above) you should probably
locate the latest edition, since the information may be outdated.
If you do not know how to get those newsgroups and/or your site does
not receive them and/or this article has already expired, you can
retrieve this FAQ from an archive site.
There exist several usenet FAQ archive sites. To find out more about
them and how to access them, please see the "Introduction to the
*.answers newsgroups" posting in news.answers.
The main FAQ archive is at rtfm.mit.edu. This document can be found
there in /pub/usenet/news.answers/x-faq/speedups. If you do not have
access to anonymous ftp, you can retrieve it by sending a mail
message to mail-server@rtfm.mit.edu with the command "send
usenet/news.answers/x-faq/speedups" in the message body.
In addition, this FAQ is available at ftp.x.org (and its mirror
sites) in /contrib/faqs/speedup-x-faq. Most X FAQs are there.
---------------
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. Historically,
"twm" was considered to be a good candidate for a speedy window manager.
A couple of generic tricks you can try to soup up your window manger,
is turning off unnecessary things like "zooming" and "opaque move".
Also, if you lay out your windows in a tiled manner, you reduce the
amount of cpu power spent in raising and lowering overlapping
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 know of that I can use on my Sun (1152x900 screen)
and still get two 80 column terminal windows side-by-side on the
display with no overlap. Other font suggestions will be accepted.
Suggestions for your consideration:
I used to recommend fvwm here, but the 2.x man page for fvwm
now says: "Although it was redesigned to minimize memory consumption,
it is now as bloated as any other window-manager. Users searching for
a low-memory consumption window-manager are advised to look elsewhere,
possibly to an earlier version of fvwm."
[thanks to: Ian Thurlbeck (ian@stams.strath.ac.uk) ]
You might want to investigate the "Lightweight Window Manager"
by Elliott Hughes. http://users.ch.genedata.com/~enh
It's reported to be quite spartan.
[thanks to: rjarvine@sitriini.hut.fi]
------------
The X Server
------------
Which Server?
- - - - - - -
Make sure that your server is a proper match for your hardware.
If you have a monochrome monitor, use a monochrome X11 server.
On my Monochrome Sun, 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 gcc (version 2.*) or with the unbundled Sun compiler.
You can expect to get "*very* large speedups in the server" by not
using the bundled SunOS compiler. I assume that similar results
would occur if you used one of the other high-quality commercial
compilers on the market.
Ben Jackson (bjj@sequent.com):
The XFree86 XF86_SVGA server that comes with the binary
distributions has support for 17 different kinds of SVGA hardware.
On any single machine installation, support for all but one can be
removed, drastically reducing the size of the server binary. This
is accomplished by installing the LinkKit distribution (available
from ftp.xfree86.org, or the mirror site where you got the rest of
the tarballs) and editing the included `site.def' definition of
XF86SvgaDrivers. More details are included in the README (installs
as /usr/X11R6/lib/Server/README). On my FreeBSD 2.0.5 machine, the
stock XF86_SVGA is 2.7M. A cirrus-only version is 1.5M, and took
less than 5 minutes to build.
Locking the Server into RAM?
- - - - - - - - - - - - - - -
It was suggested that perhaps hacking the X server so that it would
stay locked in RAM (and therefore not get paged out) might help
performances. eg: via a call to plock().
[Eric C Claeys (ecc@eperm.att.com), Danny Backx (db@sunbim.be),
Juan D. Martin (juando@cnm.us.es)]
Kenny Ranerup [kenny@axis.se] tried this a few years ago and
confirmed that it does work, and can give a noticeable speedup. But,
you must be careful that your server doesn't grow too large (ie,
close to the size of your RAM). He also makes the point that slow
interactive performace is in many cases due to client paging (paging
in libraries), and not server paging.
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 have confirmed that it works!
Warner Losh (imp@boulder.openware.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.
By using sleeps to stagger the launching of your clients in your
.Xinitrc , you avoid them fighting each other for your
workstation's 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 ) &
I've experimented with:
(sleep 1; exec xclock ) &
(sleep 2; exec xbiff ) &
(sleep 3; exec xterm ) &
(sleep 4; 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 ) &
[ 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.
Theo Honohan suggests that you might
want to investigate 'xtoolwait' (which can be found at
ftp.x.org/contrib/utilities/xtoolwait-1.1.tar.gz) which does
similar pacing of X startup.
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.
One simple strategy is to choose a small number of fonts (one small,
one large, one roman, whatever suits you) and configure all your
clients -- or at least all your heavily used clients -- to use only
those few fonts. Client programs should start up quicker if their
font is already loaded into the server. This will also conserve
server resources, since fewer fonts will be loaded by the server.
[ Farrell McKay (fbm@ptcburp.ptcbu.oz.au),
Joe English (joe@trystero.art.com) ]
eg: My main xterm font is 7x13, so I also have twm set up to use 7x13
in all its menus and icons etc. Twm's default font is 8x13. Since
I don't normally use 8x13, I've eliminated one font from my server.
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.
Anthony Stuckey (astuckey@predator.urbana.mcd.mot.com):
This is particularly good advice on Linux. Linux has a problem
with non-floating-point capable hardware (486SX's, etc) in that
they will freeze for up to a few minutes while the Scalable fonts
are created... The font server fixes this to a certain extent, as
does removing the scalable fonts from your font path. ... I believe
that a writeup of this problem is in the Linux Tips FAQ
[The main point here is that non-fpu machines, linux or otherwise,
should experience a benefit from running a font server.]
About the Resources File
- - - - - - - - - - - - -
Keep your .Xresources / .Xdefaults file small. Saves RAM and saves
on server startup time. Joe English (joe@trystero.art.com)
One suggestion:
In your .Xresources file, try putting only the minimum number of
resources that you want to have available to all of your
applications. For example: *reverseVideo: true
Then, separate your resources into individual client-specific
resource files. For example: $HOME/lib/app-defaults. In your
.login file set the environment variable XUSERFILESEARCHPATH:
setenv XUSERFILESEARCHPATH $HOME/lib/app-defaults/%N
(Note: It is easier and quicker for Xt to process
XUSERFILESEARCHPATH than XAPPLRESDIR.)
[ The "comp.windows.x Frequently Asked Questions" FAQ contains
an excellent explanation of how this and the other main X
environment variables work. --ed.]
So, when xterm launches, it loads (through Xt) its resources from
.../app-defaults/XTerm. Xdvi finds them in .../app-defaults/XDvi,
and so on and so forth. Note that not all clients follow the same
XXxxx resource-file naming pattern. You can check in your system
app-defaults directory (often: /usr/X11R5/lib/X11/app-defaults/) to
find the proper name, and then name your personal resource files
with the same name.
This is all documented in the Xt Specification (pg 125 & 666).
[Thanks to: Kevin Samborn (samborn@mtkgc.com),
Michael Urban (urban@cobra.jpl.nasa.gov),
Tom Bagli (tomb@gator.bocaraton.ibm.com),
and Mike Long (mikel@ee.cornell.edu).
Kevin is willing mail his setup files to inquirers.]
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.
It also has drawbacks:
- 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.
- xrdb will by default run your .Xresources file through cpp. When
your resources are split out into multiple resource files and
then loaded by the individual client programs, they will not.
WATCH OUT FOR THIS!!
I had C style comments in my .Xresources 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 the C style
comments in the resource files, it simply, silently, aborted
processing the resource file.
The loss of preprocessing (which can be very handy, e.g. ``#ifdef
COLOR'' ...) is enough to cause some people to dismiss 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 .Xresources.
This is because emacs (and presumably, Xvt) are not Xt based
applications. They are coded to use Xlib directly.
XUSERFILESEARCHPATH and XAPPLRESDIR are Xt features.
Larry Williamson (larry@witch.mitra.com)
- when starting up a client on a machine that does not share files
with the machine where your resources are stored, 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)
A possible compromise that I have tried, is to put resources for all
my heavily used clients (eg: xterm) into my .Xresources file, and to
use the "separate resources files" method for clients that I seldom
use.
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 ":0.0", where 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.
"I don't think it's stock MIT, but (at least) Data General and HP
have libraries that are smart enough to use local communication even
when the DISPLAY isn't set specially."
Rob Sartin (88opensi!sartin@uunet.UU.NET)
[Jody Goldberg (jody@algorithmics.com) sent me an Xlib patch to
change stock R5 to use local communication even if DISPLAY is not
properly set. I don't want to get in the business of distributing or
trying to juggle non-MIT patches and so have elected not to include
it here. Hopefully MIT will apply this minor (~8 lines) patch
themselves. In the meantime, if you want to try it yourself, email
Jody. --ed.]
-------
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.]
I've received some contradictory advice from people, on the subject
of X client programs. Some advocate the use of programs that are
strictly Xlib based, since Xt, Xaw and other toolkits are rather
large. Others warn us that other applications which you are using
may have already loaded up one or more of these shared libraries. In
this case, using a non-Xt (for example) client program may actually
_increase_ the amount of RAM consumed.
The upshot of all this seems to be: Don't mix toolkits. That is, try
and use just Athena clients, or just Xview clients (or just Motif
clients, etc). If you use more than one, then you're dragging in
more than one toolkit library.
Know your environment, and think carefully about which client
programs would work best together in that environment.
[Thanks to: Rob Sartin (88opensi!sartin@uunet.UU.NET),
Duncan Sinclair (sinclair@dcs.gla.ac.uk | sinclair@uk.ac.gla.dcs) ]
A Better Clock for X
- - - - - - - - - - -
1) xcuckoo
suggested by: Duncan Sinclair (sinclair@dcs.gla.ac.uk)
available: on export.lcs.mit.edu
Xcuckoo displays a clock in the title bar of *another* program.
Saves screen real estate.
2) Swisswatch
suggested by: Theo Honohan winDoze translation delay).
Don't know how to tune windowsNT though.
----------------------------
Other Sources of Information
----------------------------
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 is on general X information, while this FAQ concentrates
on 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).
Books & etc.
- - - - - - -
Volume 8 in O'Reilly's X Window System Series; ``X Window System
Administrator's Guide'' is a book that all X administrator's should
read. (email your snailmail address to catalog@ora.com for a catalog)
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.
[For information on The X Resource, contact paula@ora.com --ed.]
Sajee Mathew (scm@cdssua.chesapeake.com)
"Motif Debugging and Performance Tuning" by Doug Young, Prentice
Hall, 1994. Good book. The section on performance tuning presents
some useful techniques for speeding up X programs from the X-lib
and toolkit levels.
--------------
Author & Notes
--------------
This list is currently maintained by Art Mulder (art.mulder @ 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) 1993-96 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.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PLEASE NOTE: The reply address in the headers is bogus. I regret this
action, but it is necessary to ATTEMPT to defeat Junk Email robots.
--
...art mulder ( art.mulder@ualberta.ca )( http://www.ualberta.ca/~amulder/ )
( Sys Admin / Support Analyst, Network Resources )
( Computing and Network Services, U of Alberta, Edmonton )
| Back to category x-faq - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use