From: obz@sisd.kodak.com (Orest Zborowski COMP) Subject: Re: [Q] Performance of XFree86 1.2 v.v. 1.1 ??? Date: Wed, 24 Feb 1993 19:32:24 GMT
Arnd Gehrmann (arnd@rea.informatik.rwth-aachen.de) wrote:
>The time between starting startx and appearing the screen is much longer
>than under XFree86 1.1. The Performance is in that nearly as bad as in
>the older X386 V 1.1. What happend? Is it an Inst. od Config.problem?
It could be neither. First of all, this release was compiled with -m486
rather than -m386 (as 1.1 was). It shouldn't make that much of a difference
on 386 machines except that the binaries are slightly larger due to increased
padding within the code. This has not been experimentally verified yet.
Depending on how you start your X server, it could take longer to run. If
you have it autodetect your chipset and clocks, then that takes longer.
There have been some changes made to the chipset detection code, and the
clock detection is now done with somewhat greater precision. Both of these
effects are easily removed if you stuff the values into your Xconfig. As
a matter of fact, due to flakey clock detection under Linux, you should
get a good set of clocks and then stuff them into your Xconfig to avoid
problems later.
If your fonts are now compressed whereas before they weren't, then that
obviously takes more time. If it's that bad, you can simply uncompress
the fonts you want and mkfontdir in those directories. Some good candidates
would be the misc fonts and your favorite xterm font. This is probably not
that big of a deal.
If before you never ran with TCP/IP enabled, that could take some extra
time. Unfortunately, to solve this problem you need to recompile your
server - the distribution contains everything.
The server itself is larger, due to added chipset support. If you want a
smaller server, experiment with the LinkKit, where you can pick and choose
exactly what support you need. As a matter of fact, it was recommended by
the XFree86 people that only a minimal mono server be provided, with the
LinkKit providing people the opportunity to build their server.
There have also been some changes made to the heart of the server itself
(primarily with the mono driver) to make it more flexible (allowing higher
resolution mono operation, for example), at the cost of performance.
I hope this gives people a bit of an appreciation where some of the
performance juggling is done. If you really want a fast server, you'll
have to roll your own due to the many options which are available for
fine tuning. You can do some things, as outlined above, to improve your
situation, but as people have shown, there is no single silver bullet.
zorst
-- Orest Zborowski (Zorst) obz@raster.Kodak.COM