home *** CD-ROM | disk | FTP | other *** search
Xref: sparky comp.windows.x:19240 news.answers:4033 Newsgroups: comp.windows.x,news.answers Path: sparky!uunet!destroyer!cs.ubc.ca!alberta!art From: art@cs.UAlberta.CA (Art Mulder) Subject: comp.windows.x: Getting more performance out of X. FAQ Message-ID: <art.722031409@edwand> Followup-To: poster Summary: This posting contains a list of suggestions about what you can do to get the best performance out of X on your workstation -- without buying more hardware. Sender: news@cs.UAlberta.CA (News Administrator) Nntp-Posting-Host: edwand.cs.ualberta.ca Reply-To: art@cs.ualberta.ca (Art Mulder) Organization: University of Alberta, Edmonton, Canada Date: Tue, 17 Nov 1992 20:16:49 GMT Approved: news-answers-request@MIT.Edu Lines: 529 Archive-name: x-faq/speedups Last-modified: 1992/11/16 - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - THIS LIST IS STILL VERY NEW. MORE SUGGESTIONS ARE EAGERLY SOUGHT. - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - = - HOW TO MAXIMIZE THE PERFORMANCE OF X -- monthly posting More RAM, Faster CPU's, More disk space, Faster Ethernet... These are the standard responses you get when you ask about how to make your workstation go faster. Well, more hardware isn't always an option, and I wonder if more hardware is really always even a necessity. This "FAQ" list is a collection of suggestions and ideas from different people on the net on how you can the best possible performance from your workstation, WITHOUT PURCHASING MORE HARDWARE. This document is specifically concerned with X. I realize that there are a whole host of other factors that affect the performance of a workstation. Perhaps at some point, this document will grow into a generalized "System Performance Tuning" document, but for now our focus is X. [ Note: People seriously interested in the whole area of system performance, might want to look at the O'Reilly nutshell book "System Performance Tuning" by Mike Loukides. I've seen it, but not read it, so I can't comment on it's content. --ed.] ----------------- Table of Contents ----------------- 1. What about the "Other X FAQ"? 2. Window Managers 3. The X Server Which Server? Starting your Server Fonts About the Resources File Define Your Display Properly 4. Clients A Better Clock for X A Better Terminal Emulator for X 5. Miscellaneous Suggestions Pretty Pictures A Quicker Mouse Programming Thoughts Say What!? 6. Other Sources of Information 7. Author & Notes ----------------------------- What about the "Other X FAQ"? ----------------------------- David B. Lewis (faq%craft@uunet.uu.net) maintains the informative and well written "comp.windows.x Frequently Asked Questions" document. It's focus, though, is on generally useful X information, and this FAQ is focussed on the issue of performance. The comp.windows.x FAQ does address the issue of speed, but only with regards to the X server. The gist of that topic seems to be: "Use X11R5, it is faster than R4". (Please see the X FAQ for complete details). Performance is also a subjective topic, and the individual users must balance speed versus features to come to a personal decision. Therefore this document will no doubt contain lots of subjective opinions in and amongst the objective facts. --------------- Window Managers --------------- There are a lot of window managers out there, with lots of different features and abilities. The choice of which to use is by necessity a balancing act between performance and useful features. At this point, most respondents have agreed upon "twm" as the best candidate for a speedy window manager. Farrell McKay (fbm@ptcburp.ptcbu.oz.au) : I've used mwm, olwm, tvtwm, and twm. Subjectively, I think twm is the fastest. It seems to have the best performance to cost ratio, with a good feature set as well. Joe English (joe@trystero.art.com) : * Use twm or one of its variants instead of mwm. It tends to be faster in almost every operation, except mapping pop-up windows and top-level shells. * Turn off nifty features like zooming, opaque move, etc. * Lay out your windows in a tiled fashion wherever possible. Not having to raise & lower windows (generating Expose events) when switching windows helps. I've found that a good font for tiling is -misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1 (anyone know the short form for this?). It is the biggest font I have found that I can use on a SPARC ELC and still get two 80 column terminal windows side-by-side on the display with no overlap. Other suggestions will be accepted. ------------ The X Server ------------ Which Server? - - - - - - - Doesn't the old saying go: "Use the right tool for the job"? This applies to the X11 server also. Make sure that your server is a proper match for your hardware platform. Specifically, If you have a monochrome monitor, use a monochrome X11 server. On my Monochrome Sun ELC, I haven't noticed much difference between the Xsun (colour) server and XsunMono, however it was pointed out to me that XsunMono is about 800k smaller and therefore should contribute to less paging. [ thanks to: Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk), Michael Salmon (Michael.Salmon@eos.ericsson.se) ] How your server was compiled can also make a difference. Jeff Law (law@schirf.cs.utah.edu) points out that on a Sun system, you should compile X with gcc2 or with the unbundled Sun compiler, and *not* use the the SunOS 4.1.1 bundled compiler. You can expect to get "*very* large speedups in the server" that way. I would assume that similar results would occur if you used some of the other popular high-quality commercial compilers on the market. Starting your Server - - - - - - - - - - - Joe English (joe@trystero.art.com) : If you start up a lot of clients in your .xsession or whatever, sleep for a second or two after launching each one. After I changed my .xclients script to do this, logging in actually took *less* time... we have a heavily loaded system without much core, though. This sounds crazy, but I tried it, and it works! Warner Losh (imp@Solbourne.COM) provided me with a good explanation of why this works, which I have summarized here: When you start up an X server it takes a huge amount of time to start accepting connections. A lot of initialization is done by the server when it starts. This process touches a large number of pages. Any other process running at the same time would fight the server for use of the CPU, and more importantly, memory. If you put a sleep in there, you give the Server a chance to get itself sorted out before the clients start up. Similarly, there is also a lot of initialization whenever an X client program starts: toolkits registering widgets, resources being fetched, programs initializing state and "databases" and so forth. All this activity is typically memory intensive. Once this initialization is done ("The process has reached a steady state"), the memory usage typically settles down to using only a few pages. So, by using sleeps to stagger the launching of your clients in your .Xinitrc , you avoid them "fighting" each other over your workstations limited resources This whole situation is most definitely a "Your Mileage May Vary" situation, as there are so many variables to be considered: available RAM, local swap space, load average, number of users on your system, which clients you are starting etc. Currently in my .xinitrc I have a situation like: (sleep 1; exec xclock ) & (sleep 1; exec xbiff ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & I've experimented with: (sleep 1; exec xclock ) & (sleep 2; exec xbiff ) & (sleep 3; exec xterm ) & (sleep 4; exec xterm ) & (sleep 5; exec xterm ) & I've even tried: (sleep 2; exec start_X_clients_script ) & and then in start_X_clients_script I had: (sleep 1; exec xclock ) & (sleep 1; exec xbiff ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & (sleep 1; exec xterm ) & [ The idea with this last one was to make sure that xinit had completely finished processing my .xinitrc, and had settled down into a "steady state" before the sleep expired and all my clients were launched. ] All of these yielded fairly comparable results, and so I just stuck with my current setup, for it's simplicity. You will probably have to experiment a bit to find a setup which suits you. Fonts - - - Loading fonts takes time, and RAM. If you minimize the number of fonts your applications use, you'll get speed increases in load-up time. Farrell McKay (fbm@ptcburp.ptcbu.oz.au) : One small point I've noticed (not specifically related to R5) is that clients will always start up more quickly if they don't have to load a new font into the server. So I only use two or three fonts throughout the whole of my X environment. Sometimes I need to use a Kanji font (for my work) at intervals throughout the day, so in the morning I start up xfd with that font (that loads it into the server), iconify it, and leave it there for the rest of the day. Pre-loaded fonts sure cut down initialization time. Joe English (joe@trystero.art.com) : Carefully choose a small number of fonts (one fixed-width, one roman, one sans-serif, one large one, whatever else you need) and reconfigure all the applications you use to use only those fonts. This will conserve server resources and make applications start up faster. Loading fonts takes a long time. Oliver Jones (oj@roadrunner.pictel.com): Keep fonts local to the workstation, rather than loading them over nfs. If you will make extensive use of R5 scalable fonts, use a font server. About the Resources File - - - - - - - - - - - - - Joe English (joe@trystero.art.com) : Keep your .Xresources and .Xdefaults file small. Same effect as [reducing the number of fonts]. In your .Xdefaults (.Xresources) file, try just putting the minimum amount of resources that you want to have available to all your applications. For example: *reverseVideo: true Then, separate your resources into individual client-specific resource files. For Example: I store mine in $HOME/lib/app-defaults. In my .login file I set the environment variable XUSERFILESEARCHPATH: setenv XUSERFILESEARCHPATH $HOME/lib/app-defaults/%N So, when I launch an xterm, it loads it's resources from ...app-defaults/XTerm. Xdvi finds them in .../app-defaults/XDvi, and so on and so forth. Not all clients follow the same class-naming convention, so you may have some fun figuring out what to call the resource file (xterm? Xterm? XTerm?). In general, try following the standard XXxxx pattern first. This method of organizing your personal resources has the following benefits: - Easier to maintain/ more usable. - Fewer resources are stored in the X server in the RESOURCE_MANAGER property. As a side benefit your server may start fractionally quicker, since it doesn`t have to load all your resources. - Applications only process their own resources, never have to sort through all of your resources to find the ones that affect them. - the application that you are interested in has to load an additional file every time it starts up. This doesn't seem to make that much of a performance difference, and you might consider this a huge boon to usability. If you are modifying an application's resource database, you just need to re-run the application without having to "xrdb" again. This is all documented in the Xt Specification (pg 125 & 666). [Thanks to: Kevin Samborn (samborn@mtkgc.com) and Michael Urban (urban@cobra.jpl.nasa.gov) ] The "comp.windows.x Frequently Asked Questions" FAQ list contains an excellent explanation of how these environment variables work. NOTE: xrdb will by default run your .Xdefaults file through cpp. When your resources are split out into multiple resource files (as described above) and then loaded by the individual client programs, they will NOT be processed first through cpp. WATCH OUT FOR THIS!! I had C style comments in my .Xdefaults file, which cpp stripped out. When I switched to this method of distributed resource files I spent several frustrating days trying to figure out why my clients were not finding their resources. Xt did *NOT* provide any error message when it encountered those C style comments in the resource files, it simply silently aborted processing that resource file. You may also run into some clients which break the rules. For example, neither Emacs (18.58.3) nor Xvt (1.0) will find their resources if they are anywhere other than in .Xdefaults. Define Your Display Properly - - - - - - - - - - - - - - - Client programs are often executed on the same machine as the server. In that situation, rather than setting your DISPLAY environment variable to "<hostname>:0.0", where <hostname> is the name of your workstation, you should set your DISPLAY variable to "unix:0.0" or ":0.0". By doing this you access optimized routines that know that the server is on the same machine and use a shared memory method of transferring requests. [thanks to Patrick J Horgan (pjh70@ras.amdahl.com)] See the _DISPLAY NAMES_ section of the X(1) man page for further explanation of how to properly set your display name. ------- Clients ------- If you only have a few megabytes of Ram then you should think carefully about the number of programs you are running. Think also about the _kind_ of programs you are running. For example: Is there a smaller clock program than xclock? Unfortunately, I haven't really noticed that programs advertise how large they are, so the onus is on us to do the research and spread the word. [ Suggestions on better alternatives to the some of the standard clients (eg: Xclock, Xterm, Xbiff) are welcome. --ed.] A Better Clock for X - - - - - - - - - - - Richard Hesketh (rlh2@ukc.ac.uk) : xbiff and xclock are written using the X toolkit and are therefore rather large ... der Mouse (mouse@Lightning.McRCIM.McGill.EDU) : For your consideration I offer mclock, my clock program. It is non-Xt-based, which alone should help, and is extensively configurable: it can be made to look very much like MIT oclock, or mostly like xclock purely by changing resources. You can get this by anonymous ftp from larry.mcrcim.mcgill.edu (132.206.1.1), /X/mclock.shar I've tried this clock program out, and it works fine, but I haven't tried any extensive testing to see how it compares to xclock in resource consumption. One point: don't let the size of the executable fool you. The binary on my site is about 2.5 times the size of Xclock, but the author pointed out to me that mclock does *not* drag in Xaw, Xmu, or Xt, which Xclock does. Therefore, it should be lighter when running. Of course, the ultimate clock --- one that consumes no resources, and takes up no screen real estate --- is the one that hangs on your wall. :-) A Better Terminal Emulator for X - - - - - - - - - - - - - - - - - From the README file distributed with xterm: +----- | Abandon All Hope, Ye Who Enter Here | | This is undoubtedly the most ugly program in the distribution. | ... +----- Ugly maybe, but at my site it's still the most used. I suspect that xterm is one of the most used clients at many, if not most sites. Laziness? Isn't there a better terminal emulator available? See below. If you must use xterm, you can try reducing the number of saveLines to reduce memory usage. [ Oliver Jones (oj@roadrunner.pictel.com), Jonny Farringdon (j.farringdon@psychol.ucl.ac.uk) ] 1) Xvt Richard Hesketh (rlh2@ukc.ac.uk) : ... if you don't need all the esoteric features of xterm, then get hold of xvt from export.lcs.mit.edu:/contrib/xvt-1.0.tar.Z, it was written here just to save swap space as xterm is rather a hog! I've since obtained and am evaluating 'xvt' and it does seem to me to be noticeably faster than xterm, while yet coming off as a full featured "clone" of xterm -- you don't even have to rename your xterm resources as xvt pretends to be XTerm. It is missing a few xterm features that I've grown accustomed too, but I'm giving it a try. 2) mterm der Mouse (mouse@Lightning.McRCIM.McGill.EDU) : I also have my own terminal emulator. Its major lack is scrollback, but some people like it anyway. It can be had from the same site as above, in /X/mterm.src/mterm.ball-o-wax. ------------------------- Miscellaneous Suggestions ------------------------- Pretty Pictures - - - - - - - - One of the things I did when first learning to use X, was experiment with using different images as the background on my display. (via xsetroot, or xphoon, etc). I soon abandoned this practise for some very good reasons: - The more complicated your root window bitmap, the slower the server is at redrawing your screen when you reposition windows (or redraw, etc) - These take up RAM, and CPU power. I work on a Sun SPARC ELC with 8mb RAM and I'm looking for more power, I can't comprehend it when I see people with a 4mb Sun 3/60 running xphoon as their root window. If you're anything like me, you need all the screen real estate that you can get for clients, and so rarely see the root window anyway. [ Thanks to Qiang Alex Zhao (azhao@cs.arizona.edu) for reminding me of this one. --ed.] A Quicker Mouse - - - - - - - - Using xset, you can speed up how fast your pointer moves when you move your mouse. This is very subjective to personal taste of course, but I like to be able to send my pointer across the screen with just a flick of the wrist. I use "xset m 5 10", see the xset man page for further ideas & information. Hint: sometimes you may want to *slow down* your mouse tracking for fine work. To cover my options, I placed a number of different mouse setting commands into menus in my window manager. eg: (for twm) menu "mouse settings" { "Mouse Settings:" f.title " Very Fast" ! "xset m 7 10 &" " Normal (Fast)" ! "xset m 5 10 &" " System Default (Un-Accelerated)" ! "xset m default &" " Glacial" ! "xset m 0 10 &" } Programming Thoughts - - - - - - - - - - - Joe English (joe@trystero.art.com) : To speed up applications that you're developing, there are tons of things you can do. Some that stick out: * For Motif programs, don't set XmFontList resources for individual buttons, labels, lists, et. al.; use the defaultFontList or labelFontList or whatever resource of the highest-level manager widget. Again, stick to as few fonts as possible. * Better yet, don't use Motif at all. It's an absolute pig. * Don't create and destroy widgets on the fly. Try to reuse them. (This will avoid many problems with buggy toolkits, too.) * Use a line width of 0 in GCs. On some servers this makes a HUGE difference. * Compress and collapse multiple Expose events. This can make the difference between a fast application and a completely unusable one. Francois Staes (frans@kiwi.uia.ac.be) : Just a small remark: I once heard that using a better malloc function would greatly increase performance of Xt based applications since they use malloc heavily. They suggested trying out the GNUY malloc, but I didn't find the time yet. I did some tests on small programs just doing malloc and free, and the differences were indeed very noticeable ( somewhat 5 times faster) [ Any confirmation on this from anyone? --ed.] Say What!? - - - - - - Some contributors proposed ideas that seem right off the wall at first: David B. Lewis (by day: dbl@osf.org, by night: david%craft@uunet.uu.net) : How about this: swap displays with someone else. Run all your programs on the other machine and display locally; the other user runs off your machine onto the other display. Goal: reduce context switches in the same operation between client and server. I'm not in a situation where I can easily try this, but I have received the following confirmation... Michael Salmon (Michael.Salmon@eos.ericsson.se): I regularly run programs on other machines and I notice a big difference. I try to run on a machine where I will reduce net usage and usually with nice to reduce the impact of my intrusion. This helps a lot on my poor little SS1+ with only 16 MB, it was essential when I only had 8 MB. ---------------------------- Other Sources of Information ---------------------------- Adrian Nye (adrian@ora.com): A lot more tips on performance are in the paper "Improving X Application Performance" by Chris D. Peterson and Sharon Chang, in Issue 3 of The X Resource. An earlier version of this paper appeared in the Xhibition 1992 conference proceedings. This paper is absolutely essential reading for X programmers. [Seems I've got some competition. :-) --ed.] -------------- Author & Notes -------------- This list is currently maintained by Art Mulder (art@cs.ualberta.ca) Suggestions, corrections, or submission for inclusion in this list are gladly accepted. Layout suggestions and comments (spelling mistak's too! :-) are also welcome. Currently I have listed all contributors of the various comments and suggestions. If you do not want to be credited, please tell me. speedup-x-faq is copyright (c) 1992 by Arthur E. Mulder You may copy this document in whole or in part as long as you don't try to make money off it, or pretend that you wrote it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // ...art mulder Department of Computing Science \\ \\ art@cs.ualberta.ca University of Alberta, Edmonton, Canada // -- ...art mulder ( art@cs.ualberta.ca ) | "Do not be conformed to this world, Department of Computing Science | but be transformed by the renewal University of Alberta, Edmonton, Canada | of your mind, ..." Romans 12:2 
