Укроп написал(а):

Performance Tips
This page describes some tips to improve KDE performance
    правка печать    
Table of Contents

          o Introduction
          o Don't try to optimize too much
          o A fast system makes KDE run fast
          o Reducing number of running applications
          o Removing applications from the Autostart folder
          o Removing docked applications (in systray)
          o Alarm daemon and KOrganizer alarm client
          o KHotKeys
          o Artsd
          o KXKB
          o Reducing startup time
                + KDE startup sound
                + The KDE splashscreen
                + Konqueror reusing
                + Konqueror preloading
                + Scanning for Netscape plugins
                + Directory prescanning in KDM
                + Faster startup of KDE applications outside of KDE
                + Turning off system configuration startup check (kbuildsycoca)
                + Avoid very long delays by startup
          o Various KDE settings
                + Desktop background
                + Disabling various eye-candy features
                + Antialiasing
          o Not really KDE things but worth checking anyway
                + malloc()
                + Fonts (fontconfig)
                + Key composing (XIM)
                + /tmp/.ICE-unix
                + DMA for disk access



Introduction
This page is a list of tips how to improve KDE performance.

KDE is constantly being optimized, and every new KDE version is generally perceived as being more efficient than older versions. However, many aspects of KDE performance depend on the underlying system or configuration, which KDE usually cannot affect. This page lists some of the related issues together with instructions how to avoid or fix the problems.

If you would like to add new tips to this page, update the ones already listed, or discuss them, please use the kde-optimize@kde.orgexternal link mailing list. Do not edit the content of this page (except for small changes like fixing typos or improving formatting) without approval.

Don't try to optimize too much
Take care, especially if you're less experienced. It is possible to change your settings so much that KDE won't work correctly anymore. For example, don't remove things from the startkde script unless you have a way to roll back your changes from the shell if something unexpected happens. Most of the tips have a short summary of the benefits and disadvantages of following them. Evaluate the potential value of implementing tips, and the risks too, if any.

A fast system makes KDE run fast
This may seem obvious, and may not appear to be a performance tip, but it is in fact the thing that is guaranteed to make the biggest performance improvement, and that's why it is here, whether one likes it or not. A computer with 1GHz processor and 256MB RAM (a configuration which is probably not even being offered by shops these days anymore) is perfectly sufficient for decent KDE performance.

Computers get more powerful, and more features, faster development times and better quality result in more demanding software. KDE will probably never run acceptably on a 100MHz 32MB RAM computer, just like Microsoft Windows 95, almost ten years old software by now, has never run acceptably on PC i386 with 4MB RAM, which would be more than enough for software twenty years old.

KDE is mostly developed by volunteers working on KDE in their spare time. And optimizing software is a difficult, time-consuming and tedious work. People who think KDE is too slow and inefficient are welcome to join and work on optimizing KDE even further.

It is also not fair to compare KDE to environments such as WindowMaker, because that is like comparing a Jumbo Jet and a glider. A glider may be perfectly fine for some people, but it is not going to fly several hundred people thousands of kilometers away. The same way WindowMaker is not going to help in any way with developing applications or having a consistent GUI. In fact WindowMaker with several applications running using different development frameworks may be eventually more resource demanding than the KDE equivalents.

A system is not only the hardware, but also the software. KDE should not be expected to run at its maximum performance on a system which is already several years old. While new features in new software versions may have negative performance impact, software is also being optimized and problems are being fixed. For example Linux kernel version 2.6 is generally perceived as having better performance than version 2.4. Also KDE may rely on new features or fixes in system libraries in order to perform better. The same way KDE itself is constantly being improved and optimized, and newer KDE versions generally have better performance (some of the tips listed below rely on a certain minimal KDE version).

Reducing number of running applications
Every KDE application (process, to be precise) requires certain amount of memory to run and certain time to start up. Therefore reducing their number will reduce memory usage, and if they're started during KDE startup, also reduce KDE startup time.
In Konsole, do 'ps x', or use KDE System Guard, you'll see a list of all processes you're running as the user. Processes that are required for KDE desktop are startkde, kdeinit (shown as 'kdeinit: Running...' in the 'ps ux' output), dcopserver, klauncher, kded, ksmserver (shown twice, once as 'kwrapper ksmserver'), knotify, kwin, kdesktop and kicker. You may also ignore kioslaves (kio_file etc.), as those are automatically terminated after being idle for some time. Some of the remaining processes may be required for functionality you expect from KDE, but you can check the list and find processes that you don't need.

Removing applications from the Autostart folder
Visit the directory /opt/kde3/share/autostart/ (this assumes that /opt/kde3 is the KDE installation prefix). The desktop files located there will be started automatically when the KDE desktop starts. Remove the desktop files you don't need. If you don't want to delete them, create a new folder /opt/kde3/share/autostart_bak/ and move the desktop files you don't need there.

Note that many of the files specify a startup condition, which allows turning them off from the GUI, without removing the file. Also note that several core components such as the panel are started this way, so removing entries without knowing what they do may result in reduced KDE functionality.

Removing docked applications (in systray)
Most of systray icons represent one application, so you can try removing as many of those as possible. Moreover there are panel applet equivalents for many docked applications, so you won't lose the functionality in such cases (in fact some of the applets may be even considered superior), and panel applets don't require their own process.
Note that some docked applications need to be explicitly disabled in their configuration in order not to be started after next KDE startup, or you need to confirm while removing them that you don't want them to restart next time.

Using applets instead of docked applications reduces KDE startup time and memory usage.

Alarm daemon and KOrganizer alarm client
You can turn off the alarm daemon and KOrganizer alarm client if you don't need them. Alarm daemon is turned off in the control center in KDE Components/Service Manager. For the KOrganizer alarm client, right click on it, disable 'Start Alarm Client at Login' and quit it.

Disabling alarm daemon and KOrganizer alarm client will reduce KDE startup time and memory usage at the expense of not having alarms.

KHotKeys
If you have running process 'khotkeys', it's used for starting applications from K-Menu using keyboard shortcuts. In KDE 3.2 it's also responsible for mouse gestures. If you don't want it running, delete all actions in the KHotKeys KControl module, or delete file $KDEHOME/share/config/khotkeysrc.

KDE 3.4 and newer: KHotKeys has been turned into a KDED module, which means it no longer runs in its own process. Therefore this tip applies only to KDE 3.3.x and older.

Disabling KHotKeys will reduce KDE startup time and memory usage at the expense of not being able to assign keyboard shortcuts for launching K-Menu entries or to use mouse gestures.

Artsd
Disable the artsd sound server in its control center module. Note that obviously without the sound server running, applications using aRts for sound won't work, so this is useful mainly if you don't use aRts or don't have a soundcard.

Note that many multimedia applications can be configured to use other sound system than aRts, or don't depend on aRts at all. Also, for system notifications, you can configure an external player for the sounds instead of aRts (in the System Notifications control module, use the Player Settings button, and enter e.g. "aplay" for using ALSA play directly).

Disabling artsd startup will reduce KDE startup time and memory usage at the expense of having no sound in aRts applications.

KXKB
If you're using KXKB, the docked application for keyboard layouts, you may try disabling it, and either configuring your keyboard layout directly in the XF86config file (consult its manual page), or adding shell script calling setxkbmap (consult its manual page) to your Autostart folder.

Disabling KXKB reduces KDE startup time and memory usage.

Reducing startup time

KDE startup sound
Turning off the KDE startup sound will slightly reduce the KDE startup time. The KDE startup sound can be disabled in the System Notifications control module, either by turning off all sounds, or by selecting "KDE System Notifications" as event source and turning off only the sound for the "KDE is starting up" event.

KDE 3.4: A special code handling events during KDE startup has been added, which should delay startup of the KNotify notification daemon in case all those events are configured to be turned off. So turning off the KDE startup sound will additionally avoid one KDE process started during KDE startup, making KDE startup faster.

The KDE splashscreen
Try disabling the splashscreen shown during KDE startup. Currently, you can do so only by editing the startkde script. As user root, modify $KDEDIR/bin/startkde and remove the line saying 'ksplash --nodcop'. Note that disabling the splashscreen may actually make KDE startup seem to take longer because of the missing feedback.

KDE 3.4: In the list of available splashscreens in its control module, there are two options "None" and "Simple", first of them turning the splashscreen off completely, second selecting a very simple optimized splashscreen.

Disabling ksplash reduces KDE startup time.

Konqueror reusing
In order to reduce time needed for opening new Konqueror windows, Konqueror may be configured to reuse already running processes instead of starting new ones. The setting in the control center in File Browsing/File Manager (the 'Minimize Memory Usage' radio buttons). It may be set to 'Never', which disables Konqueror reusing and always starts a new instance, making all Konqueror windows independent, and when one of them crashes, others are unaffected. Next two values are 'For local browsing' and 'For web browsing', which will reuse already running Konqueror instance (if there's any) if you requested to open a new window for browsing local files or web pages respectively. The last value is 'Always', causing Konqueror processes to be reused independent of what you're browsing. The default value is reusing for local browsing, which should be safe. Unless you're experiencing Konqueror crashes, you can try setting it to 'Always'. In such case it may also help to have always one Konqueror window open unused.

Having Konqueror configured for reusing processes often reduces memory usage and time needed for opening new Konqueror windows, at the expense of losing more Konqueror windows in case of a crash.

Konqueror preloading
Another possibility reducing time needed for opening new Konqueror windows is enabling so-called Konqueror preloading. With the option enabled, when a Konqueror process should be terminated because its last window is closed, it will be kept running without a window only hidden, and reused next time a Konqueror window is needed. The setting is in the Performance tab in Konqueror's settings, or in the Control Center in KDE Components/Performance. It is possible to specify maximum number of instances kept in the background, and whether such instances should be even explicitly loaded for preloading, for example at KDE startup.

Enabling Konqueror preloading often reduces time needed for opening new Konqueror windows, at the expense of having memory used by Konqueror even if no window is open.

Scanning for Netscape plugins
It's possible that your KDE is configured to scan for new Netscape plugins during every startup, which is unnecessary and may be turned off (you'll have it run it manually in such case when there will be changes though). Check that your startkde script doesn't contain any call to nspluginscan. Also check in Konqueror's settings that in the module Plugins that the checkbox "Scan for new plugins at KDE startup" is disabled. There's also a button for manual search in case you installed a new plugin.

Disabling scanning for Netscape plugins reduces KDE startup time.

Directory prescanning in KDM
Loading data from disk is slow, especially when disk seeks are involved (e.g. when
searching directories). During KDE startup a large amount of data needs to be loaded,
and many files need to be accessed. The impact of disk reading can be demonstrated
by the fact that when starting KDE, immediately logging out and starting KDE again,
the second startup takes only half the time on the average. This is caused by recently
accessed disk data being stored in memory caches, which considerably speeds up
repeated attempts to read this data.

KDM, the KDE login manager, offers the possibility to start a task that will be running
in the background while the login screen is either idle or while the login information
is being filled in, and this task will be terminated right before KDE loading starts.
It is possible to configure a task that will read data that are accessed during KDE
startup, thus loading them into memory caches and reducing the number of disk accessed
during the actual KDE startup.

The command to run is specified in KDM's configuration file, usually /opt/kde3/share/config/kdm/kdmrc or /etc/opt/kde3/share/config/kdm/kdmrc (this tip assumes KDE is installed in /opt/kde3 - all paths need to be modified if the location is different). The options should be specified in the group [X-*-Greeter] as 'Preloader=command', where command can be e.g. '/opt/kde3/bin/preloadkde'.
The actual script should contain something like:

exec find /etc/opt/kde3 /home/user/.kde /opt/kde3/share/applications \
    /opt/kde3/share/applnk /opt/kde3/share/mimelnk /opt/kde3/share/services \
    /opt/kde3/share/servicetypes /opt/kde3/share/config \
    /opt/kde3/share/icons /opt/kde3/


/home/user is the home directory of the user who uses the computer (this assumes there is only one user on the computer using KDE). If there are more users, it might be better to avoid specifying any home directory.

Warning: The 'exec' in the script is necessary. The script should not start any subtasks, as they will not be terminated by KDM before launching KDE. That would result in actually slowing KDE startup.

Note that this option has no effect if KDM is configured to perform automatic login, because there is no idle period during which the data could be read from the disk.

Also, massive disk accessing in the background may slightly affect the responsiveness of the foreground application, making KDM feel slightly less responsive. As keyboard input is queued for processing, this should not be a problem in practice though.

A mechanism for the Linux kernel is currently being developed that will precache disk contents needed during startup.

Prescanning directories in KDM reduces KDE startup time, but may make KDM appear to be slightly less responsive.

Faster startup of KDE applications outside of KDE
KDE applications usually require several small KDE daemons (kdeinit, dcopserver, klauncher, kded) to be running. These daemons are launched during first phases of KDE startup, so they are normally available in a KDE session. However when a KDE application is launched outside of KDE, and these daemons are not running (i.e. no other KDE application is running), they need to be launched first. This makes the startup of the KDE application somewhat longer. Since the daemons automatically terminate after a small delay when the last KDE application running exits, repeated usage of a single KDE application outside of KDE can make its startup appear longer than it really is.

In order to avoid this, KDE daemons can be launched manually, in which case they will remain running even if no KDE application is running. This can be achieved by running 'kdeinit'. This command should be launched in some startup script, or specified as startup command in the GUI used (using some equivalent of KDE's Autostart folder).

One problem with having KDE daemons running permanently is the fact that some of them keep a connection to the X server, which for example prevents logout from ssh session with X forwarding. To avoid this problem, the daemons should be terminated manually by running 'dcopserver_shutdown' (this command should be specified in a logout script).

Keeping KDE daemons running permanently in non-KDE GUI will reduce startup time of KDE applications at the expense of more memory used.

Turning off system configuration startup check (kbuildsycoca)
KDE system configuration (installed applications, mimetypes, etc.) is specified as many so-called .desktop files. This has several technical benefits, but the disadvantage is that checking and using so many files has a negative performance impact. For this reason KDE includes a mechanism called KSyCoCa (KDE System Configuration Cache), which is a single file that stores all the information provided by .desktop files in a format which is very efficient to use. This avoids the performance problem for KDE applications.

For obvious reasons it must be ensured this file does not contain obsolete information. Therefore while KDE is running, a daemon watches for changes in the .desktop files, and triggers rebuilding the ksycoca file in such case. However, during KDE startup, it is not known if the .desktop files have changed since the last time or not. Any application, even a non-KDE one, can install new .desktop files, and there's no mechanism to check for updates if KDE is not running. Therefore a check of all the files needs to be done during KDE startup. This check is very optimized in the usual case (only a check of timestamps), however searching many directories with files is inefficient.

KDE allows disabling this check of the .desktop files, in the Performance module in the Control Center. The option will delay the check by 60 seconds, thus avoiding searching of the directories during KDE startup. This option can lead to problems in rare cases though, these problems include missing applications in the K Menu, missing mimetypes, and similar. Since changes to .desktop files mostly happen by installing and uninstalling applications, it is recommended this option is at least temporarily turned off during doing so (alternatively, it is possible to run 'kbuildsycoca' manually as the user before logging into KDE, or waiting 60 seconds before using newly installed software).

Due to these possible problems, the usage of this option is not recommended, and is meant only for people who are aware of the possible problems and want to reduce KDE startup time as much as possible. The KDE crash handler will refuse to provide a backtrace in case it detects this option is turned on (unless it is configured to run in the developer mode), and you will need to turn the option off and reproduce the problem again in order to get a backtrace for the bugreport.

This option also affects launching KDE applications outside of KDE in case no other KDE application is used. In such case several small KDE daemons need to be launched first, and checking of .desktop files is done by one of the daemons. In this case it is however recommended to have the daemons running permanently for even better (see the tip dedicated to this case).

Note that the prescanning in KDM described in another tip also reduces the benefits of disabling system configuration startup check.

Turning off system configuration startup check reduces KDE startup time, but may in rare cases lead to various problem, and as such its usage is discouraged.

Avoid very long delays by startup
If the loopback interface is not configured, KDE startup could easily take 10 minutes, probably due to the fact, that it tries to reach localhost, without success... As there is no error message, and later the system is fully functional, it's pretty hard to find out what went wrong... So if you experience such an 'endless' delay by startup, check '/etc/network/interfaces'... Or simply do a 'ping localhost'...

Various KDE settings

Desktop background
Use only single color or simple horizontal/vertical gradient for desktop background, with no wallpaper.

Using simple desktop background will reduce KDE startup time and memory usage.

Disabling various eye-candy features
Obviously, KDE without fading menus, transparency, animated icons and similar should run somewhat faster.

    * How do I configure this?
          o Open Control Center.
          o Go to Appearance & Theme and click on Theme Manager.
          o Find Customize your theme: at the bottom of the window. Click on Style.
          o Choose tab Effects.
          o Uncheck Enable GUI effects.
          o Click OK.
          o Hint: This change will only affect newly started applications.


Antialiasing
Having antialiasing (AA) turned on slows down drawing of texts, so you may consider turning it off in the control center, in the fonts module.

Not really KDE things but worth checking anyway

malloc()
Function malloc() is responsible for dynamic allocation of memory, and is called very often in KDE applications. KDE therefore performs worse on systems with inferior malloc() implementations. For this reason KDE includes its own optimized version of malloc(), which may be enabled during building the kdelibs package by using the --enable-fast-malloc configure switch. Consult file kdelibs/kdecore/malloc/README for details.

This option is not necessary with Linux kernel v2.6 and glibc-2.3, it however provides noticeable performance boost with glibc-2.2. It is possible this option provides performance boost also on other platforms.

Note: In rare cases, there may be conflicts between the system and KDE versions of malloc, leading to crashes.

Fonts (fontconfig)
Current versions of the fontconfig library have rather inefficient handling of fonts, meaning that the more fonts are installed, the longer and the more memory will every KDE application use. Therefore removing as many fonts as possible will improve KDE performance.
As root, run 'fc-cache -v', which will list directories where fontconfig looks for fonts, and the number of fonts in each of those directories. The first step is to uninstall unnecessary font packages using the package management for your distribution. More experienced users can selectively remove fonts manually from the directories.
Truetype fonts should be in general preferred to bitmap fonts, because you don't need different versions of the same font for different sizes. Also, bitmaps fonts often tend to be compressed (.pcf.gz), so they additionally need to be uncompressed by the application before being usable.

Warning: Removing fonts may seriously affect the appearance of your desktop, or even make it completely unusable if you remove important fonts. Reducing the number of fonts reported by fc-cache to less than 100 already requires a lot of checking.

KDE 3.3: KDE has a workaround in kdeinit which tries to reduce the impact of this fontconfig inefficiency. For this workaround to work, at least fontconfig version 2.2.3 (or development version 2.2.96) needs to be installed.

Fontconfig developers have been notified about the problem (http://freedesktop.org/pipermail/fontconfig/2004-June/000937.htmlexternal link), however it's not known when this problem will be fixed.

Reducing number of installed fonts will reduce memory usage and startup time of KDE applications. As long as only unused fonts are removed, there should be no negative effect.

Key composing (XIM)
In many languages, some characters are not entered by pressing only a single key (possibly with some modifiers pressed), but by a sequence of keys. This applies e.g. to accented characters, when first a key with the accent needs to be pressed, and then the key with the unaccented version of the character. Current versions of X11 libraries responsible for this key composing have a rather inefficient handling of the list of such compositions, especially in UTF8 locales where the composition table is very large.
Users can install their own version of the composition table in file .XCompose located in their $HOME directory. If you don't use composing (or don't know what it is), you can simply create empty .XCompose file. In other cases, it is possible to copy a compose file from the standard location (/usr/X11R6/lib/X11/locale/encoding/ , where encoding is the locale's encoding, or en_US.UTF-8 for UTF8 locales).
For users without knowledge to edit the file manually, it is possible to use this scriptexternal link which will create a subset of the full UTF8 compose file (in Konsole, 'echo $LANG' should reveal if UTF8 locale is used or not - it is in most recent distributions). The script needs to be run as './compose_locale_subset.sh Compose.utf8 Compose.locale >Compose.new', and the script will try to find all entries from the locale file in the UTF8 file and output them (it is not possible to use the locale compose file directly because it is not in the UTF8 encoding). Since most people need compositions only for their language, this locale subset should be sufficient.
Additionally, the compositions involving the Compose key (Multi_key) may be removed too if they are not used. This can be achieved by running 'cat Compose.old | grep -v 'Multi_key' >Compose.new'.
For your convenience, there are resulting files for X.Org version 6.8.1 for some locales provided at http://ktown.kde.org/~seli/ximexternal link .

X.Org developers have been notified about the problem, and a patch fixing the issue is being developed.

Using a smaller XIM compose file will reduce startup time and memory usage of KDE applications, at the expense of not having all compositions available.

/tmp/.ICE-unix
Make sure the directory /tmp/.ICE-unix exists, is owned by user root and has permissions 1777 (accessible to all and sticky). The command 'ls -ld /tmp/.ICE-unix' should show something like

drwxrwxrwt 2 root root 176 2003-01-06 21:25 /tmp/.ICE-unix/

First, third and fourth columns should be like shown above. When this directory isn't created correctly, you may also see message 'IceTransmkdir: Owner of /tmp/.ICE-unix should be set to root' in your ~/.xsession-errors file.

To fix the problem, put the following commands in your system startup scripts (e.g. /etc/init.d/boot.local or /etc/rc.d/rc.local):

chown root:root /tmp/.ICE-unix
chmod 1777 /tmp/.ICE-unix


Note that with the latest version of the X.Org XServer your desktop will be unusable without properly setup /tmp/.ICE-unix, so this problem will hopefully soon become a history.

Having correctly setup /tmp/.ICE-unix saves 5 seconds from the startup time.

DMA for disk access
Make sure that you have not disabled DMA (Direct Memory Access for transfers) for disks. While most modern distributions already enable this by default, and modern disks should not have any problems with it, DMA may be still disabled by default on some systems. Some distributions have configuration tools for DMA, or you can check and setup it manually.

As user root, type 'hdparm /dev/hda', where /dev/hda is your disk device. It should also print line 'using_dma = 1 (on)', if it says 'off', you could try turning it on. In order to turn DMA on, type 'hdparm -d1 /dev/hda' (use 'hdparm -t /dev/hda' to check disk throughput). Note that if you explicitly need to turn DMA on, you'll have to do it after every boot, so you should put the command in your system startup scripts. Consults the manual page for hdparm for details and possible problems, especially options -c, -d, -X, -k and -m.

On Redhat and Redhat-like systems, uncomment the line USE_DMA=1 in the file /etc/sysconfig/harddisks to enable DMA with each boot.

FreeBSD variant (from Mark Rowlands): Type 'sysctl hw.ata.ata_dma', it should return 1 indicating disk is using DMA. If it's not set, put 'hw.ata.ata_dma=1' in your /boot/loader.conf. You may also check hw.ata.wc and hw.ata.tags. Please consult manpages for ata(4), atacontrol(4) and sysctl(8) for details and possible problems.

Extra tuning parameters: There exists two more commonly unused optimizations with IDE hard drives. The first is the -c option, which turns on 32 bit transfers across the BUS / VLB to the interface card. "hdparm -c1 /dev/hda" is the fastest option, -c3 works for buggier hardware/drivers. The other option is slightly more dangerous and one should definitely consult the man pages before using it: "hdparm -u1 /dev/hda" sets the unmask irq flag on the drive. From the man pages: "This permits the driver to unmask other interrupts during processing of a disk interrupt, which greatly improves Linux's responsiveness".

People from #kde-freebsd also pointed out http://www.freebsd.org/cgi/man.cgi?tuningexternal link as a good manpage about general FreeBSD tunning.

Having DMA enabled decreases CPU usage and increases disk throughput.

Contributors to this page: bygdog708 points  , luci1428 points  , JeramyRutley6 points  , Seli72 points  , cm488 points  and 0 points  .
Последнее изменение старницы Суббота 26 of Август, 2006[00:43:43 UTC] автор bygdog708 points .

The content on this page is licensed under the terms of the GNU Free Documentation License.

Это не я бляяя...