home *** CD-ROM | disk | FTP | other *** search
- 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
- From: check.the.signature@nospam.ualberta.ca (Art Mulder)
- Newsgroups: comp.windows.x,news.answers,comp.answers
- Subject: comp.windows.x: Getting more performance out of X. FAQ
- Supersedes: <x-perf_905155921@rockpile.ucs.ualberta.ca>
- Followup-To: poster
- Date: 5 Oct 1998 08:13:25 GMT
- Organization: University of Alberta, Edmonton, Canada
- Lines: 833
- Approved: news-answers-request@MIT.Edu
- Message-ID: <x-perf_907575121@rockpile.ucs.ualberta.ca>
- Reply-To: check.the.signature@nospam.ualberta.ca (Art Mulder)
- NNTP-Posting-Host: rockpile.ucs.ualberta.ca
- Summary: This posting contains a list of suggestions about what you
- can do to get the best performance out of X on your
- workstation -- without buying more hardware.
- Keywords: FAQ speed X
- Xref: senator-bedfellow.mit.edu comp.windows.x:125503 news.answers:141843 comp.answers:33420
-
- 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 <th208@cam.ac.uk> 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 "<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.
-
- "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 <th208@cam.ac.uk
- ftp://sunsite.doc.ic.ac.uk/packages/X11/R5contrib/swisswatch-0.06.tar.Z
-
-
- 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
- Suggested by: Richard Hesketh (rlh2@ukc.ac.uk)
- Author: John D. Bovey (jdb@ukc.ac.uk)
- Available: http://unix.hensa.ac.uk/pub/misc/unix/xvt
-
- [From the README file] "Xvt is an X terminal-emulator that is
- designed to be more or less compatible with xterm while using much
- less swap space. It is mainly intended for use at sites which use
- large numbers of X terminals but may also be useful on single
- workstations that are short of memory. On a [SunOS 4.1.* Sparc], an
- initially invoked xvt uses about 1/3 megabyte of swap while xterm
- uses about 1.3 megabytes (obtained by running pstat rather than ps
- which seems to give unreliable size figures on SPARCs). The main
- way that xvt achieves its small size is by avoiding the use of the X
- toolkit."
-
- There have been some conflicting opinions aired over xvt vs. xterm.
- Different sites with different needs will likely have to do
- their own evaluation. Caveat Emptor, your mileage may vary.
-
- 2) rxvt
- Available: http://babayaga.math.fu-berlin.de:80/~rxvt/
-
- Originally a stripped down Linux port of xvt, with some
- minor modifications, it's now being actively developed
- on it's own.
- [thanks to: Theo Honohan <th208@cam.ac.uk for the update]
-
-
- Other Client Comments
- - - - - - - - - - - -
- When using the xlock screen locking client, the "qix" mode is
- much more lightweight than the default mode.
- [Q. Alex Zhao (azhao@cc.gatech.edu)]
-
- I can confirm the previous report from personal experience here. In
- a lab full of ~20 sun 3/80's all running the Xkernel software, the
- subnet was getting regularly clobbered. This was tracked down to
- students running xlock. Since these machines are all xterminals, the
- actual xlock program runs remotely, and generates a scary amount of
- network traffic to draw the default 'swarm' pictures on the screen.
- We have removed this program and replaced it with a much simpler
- screen locking program which simply blanks the screen. [ed.]
-
- A suggestion: xtrlock, by Ian Jackson (ijackson@nyx.cs.du.edu)
- It is very small (about 16k running), and doesn't produce any traffic
- while locked. Drawback: It doesn't make your screen invisible.
- [ Klamer Schutte (klamer@ph.tn.tudelft.nl) ]
-
- An improved xbiff: Xbuffy. It can watch multiple mailboxes and can
- do a pop up showing the From and Subject line of incoming mail.
- Xbiff doesn't eat much memory and Xbuffy tends to be about the same
- (on the RS/6000, xbuffy tends use just a little less memory). It is
- in the contrib directory on ftp.x.org.
- [ Bill Pemberton (wfp5p@virginia.edu) ]
-
- Tuning your client
- - - - - - - - - - -
-
- Suggestions on how you can tune your client programs to work faster.
-
- From Scott Barman (scott@asd.com) comes a suggestion regarding Motif
- Text Field Widgets:
-
- I noticed that during data entry into Motif text field widgets, I
- was getting a slight lag in response to some keystrokes,
- particularly the initial one in the field. Examining the what was
- going on with xscope I found it. It seems that when the resource
- XmNblinkRate is non-zero and the focus is on a text field widget
- (or even just a text widget) the I-beam cursor will blink. Every
- time the cursor appears or disappears in those widgets, the widget
- code is making a request to the server (CopyArea). The user can
- stop this by setting the resource XmNblinkRate to 0. It is not
- noticeable on a 40MHz SPARC, but it does make a little difference
- on a [slower system].
-
- This specific suggestion can probably be applied in general to lots
- of areas. Consider your heavily used clients, are there any minor
- embellishments that can be turned off and thereby save on Server
- requests?
-
- -------------------------
- Miscellaneous Suggestions
- -------------------------
-
- Pretty Pictures
- - - - - - - - -
- Don't use large bitmaps (GIF's, etc) as root window backgrounds.
-
- - 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 and I'm
- conscious of performance issues, I can't comprehend it when I see
- people with a 4mb Sun 3/60 running xphoon as their root window.
-
- I'll let someone else figure out how much RAM would be occupied by
- having a full screen root image on a colour workstation.
-
- - If you're anything like me, you need all the screen real estate
- that you can get for clients, and so rarely see the root window
- anyway.
-
- [ Thanks to Qiang Alex Zhao (azhao@cs.arizona.edu)
- for reminding me of this one. --ed.]
-
- A Quicker Mouse
- - - - - - - - -
- Using xset, you can adjust how fast your pointer moves on the screen
- when you move your mouse. I use "xset m 3 10" in my .xinitrc file,
- which lets me send my pointer across the screen with just a flick of
- the wrist. See the xset man page for further ideas and information.
-
- Hint: sometimes you may want to *slow down* your mouse tracking for
- fine work. To cover my options, I have placed a number of different
- mouse setting commands into a menu in my window manager.
-
- e.g. (for twm) :
- menu "mouse settings" {
- "Mouse Settings:" f.title
- " Very Fast" ! "xset m 7 10 &"
- " Normal (Fast)" ! "xset m 3 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.]
-
- Andre' Beck (Andre_Beck@IRS.Inf.TU-Dresden.de) :
-
- - Unnecessary NoExpose Events.
-
- Most people use XCopyArea/XCopyPlane as fastest blit routines, but
- they forget to reset graphics_exposures in the GC used for the
- blits. This will cause a NoExpose Event every blit, that, in most
- cases, only puts load onto the connection and forces the client to
- run through its event-loop again and again.
-
- - Thousands of XChangeGC requests.
-
- This "Gfx Context Switching" is also seen in most handcoded X-Apps,
- where only one or few GCs are created and then heavily changed
- again and again. Xt uses a definitely better mechanism, by caching
- and sharing a lot of GCs with all needed parameters. This will
- remove the load of subsequent XChangeGC requests from the
- connection (by moving it toward the client startup phase).
-
- Backing Store
- - - - - - - -
- Joe Nardelli (nardelli@mitre.org) :
- I've found that using 'backing store' really speeds up redrawing of
- complex windows. Ex: I have a window that stores an intricate 3-D
- sceen, and redrawing it every time a window pops up in front is a
- real waste of time. It is much quicker to set the 'backing store'
- attribute to either 'Always' or 'WhenMapped'. ... Note that the
- server keeps a copy of the window in memory, so very simple windows
- may actually slow some systems done. Your mileage may vary.
-
- Here is another way of looking at the issue of backing store.
- If you are low on memory, you should disable backing store, since a
- redraw will be quicker than pulling the saved image from swap space.
- (We are assuming here that you are sufficiently low on memory that
- your backing store ends up in swap space) If you have enough memory,
- backing store will beat redraw all the time -- unless you have _very_
- fast hardware.
- [from discussions with Nicolai Langfeldt (janl@ifi.uio.no) ]
-
- Say What!?
- - - - - - -
- Some contributors proposed ideas that seem right off the wall at first:
-
- David B. Lewis (by day: dbl@osf.org, by night: david%craft@uunet.uu.net) :
- How about this: swap displays with someone else. Run all your
- programs on the other machine and display locally; the other user
- runs off your machine onto the other display. Goal: reduce context
- switches in the same operation between client and server.
-
- I'm not in a situation where I can easily try this, but I have
- received the following confirmation...
-
- Michael Salmon (Michael.Salmon@eos.ericsson.se):
- I regularly run programs on other machines and I notice a big
- difference. I try to run on a machine where I will reduce net usage
- and usually with nice to reduce the impact of my intrusion. This
- helps a lot on my poor little SS1+ with only 16 MB, it was
- essential when I only had 8 MB.
-
- Casey Leedom (casey@gauss.llnl.gov) :
- [The X11 Server and the client are] competing for the same CPU as
- your server when you run it on the same machine. Not really a
- major problem, except that the X11 client and the server are in
- absolute synchronicity and are context thrashing.
-
- Timothy H Panton (thp@westhawk.uucp) :
- Firstly it relies on the fact that most CPU's are mostly idle, X's
- cpu usage is bursty. so the chances of you and your teammate
- doing something cpu-intensive at the same time is small. If they
- are not then you get twice the cpu+memory available for your
- action.
-
- The second factor is that context switches are expensive, using 2
- cpu's halves them, you pay a price due to the overhead of going
- over the network, but this is offset in most cases by the improved
- buffering of a network (typically 20k vs 4k for a pipe), allowing
- even fewer context switches.
-
- Network Issues (TCP)
- - - - - - - - - - - -
-
- It is questionable whether the following belongs in this FAQ, since
- it seems to mostly be a question of network performances. But here
- it is:
-
- Bob Arendt (rdarendt@mcmail.com) :
-
- It turns out that matching TCP sendspace and recvspace on client
- and server can dramatically affect performance. Sun/UNIX and
- TCPware/VMS default to 4Kbyte buffer sizes (out-of-the-box).
- Ultrix/DEC and DigitalUnix/DEC default to 32Kbyte buffer sizes.
- Using the same workstation hardware and FDDI network connections
- I got the following stats:
-
- x11perf -putImage100 (run on TCPware/VMS client, default 4K)
- = 4.5 msec with TCPware/VMS server, default 4K
- = 600 msec with Ultrix/VMS server, default 32K
- = 600 msec with DigitalUnix server, default 32k
-
- Changing the Ultrix config and DigitalUnix kernal to 4K TCP
- send/recv sizes resulted in matching speeds of 4.5 msec. In this
- case, less was more :-)
-
- X11 must use system TCP default buffer settings. With a
- mismatched, large recvs pace, it appears that polling mechanism
- (ala select()?) empties the buffers rather than triggering on
- buffer-full. Matching to small buffers is probably better than
- larger buffers since it tends to reduce latency and most network
- devices break up traffic into smaller chunks anyway.
-
- This also appears to be an issue for Windows/X11 servers.
- Running windowsNT on the same Dec Alpha with a third-party X11
- server I see the same dismal response times. I suspect it's the
- same problem (in conjuncution with X11->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 )
-