]> pere.pagekite.me Git - homepage.git/commitdiff
Improve language.
authorPetter Reinholdtsen <pere@hungry.com>
Fri, 6 Apr 2012 20:22:47 +0000 (20:22 +0000)
committerPetter Reinholdtsen <pere@hungry.com>
Fri, 6 Apr 2012 20:22:47 +0000 (20:22 +0000)
blog/data/2012-04-06-skolelinux-slowkdenfs.txt

index 6b297ac2741339b3c5263a9e01493bb19e14ab63..b786bb7b0fcbf2433896e6f908629af9b334d45b 100644 (file)
@@ -2,26 +2,27 @@ Title: Why the KDE menu is slow when /usr/ is NFS mounted - and how to fix it
 Tags: english, debian edu
 Date: 2012-04-06 22:20
 
-<p>Recently I have worked on speeding up a
-<a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
-installation using LTSP diskless workstations, and in the process I
-discovered something very surprising.  The reason the KDE menu is
-responding slow when using it for the first time, is due to the way
-KDE find application icons.  I discovered that showing the Multimedia
-menu would cause more than 20 000 IP packages to be passed between the
-LTSP client and the NFS server.  Most of these were NFS LOOKUP calls,
-resulting in a NFS3ERR_NOENT response.  Looking at the strace of
-kicker in Lenny (or plasma-desktop i Squeeze - same problem there), I
-see that the source of these NFS calls are access() system calls.  KDE
-can do hundreds of access() calls to find one icon file.  In my
-example, just finding the mplayer icon required around 230 access()
-calls.</p>
+<p>Recently I have spent time with
+<a href="http://www.slxdrift.no/">Skolelinux Drift AS</a> on speeding
+up a <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
+Lenny installation using LTSP diskless workstations, and in the
+process I discovered something very surprising.  The reason the KDE
+menu was responding slow when using it for the first time, was due to
+the way KDE find application icons.  I discovered that showing the
+Multimedia menu would cause more than 20 000 IP packages to be passed
+between the LTSP client and the NFS server.  Most of these were NFS
+LOOKUP calls, resulting in a NFS3ERR_NOENT response.  Looking at the
+strace of kicker in Lenny (or plasma-desktop i Squeeze - same problem
+there), I see that the source of these NFS calls are access(2) system
+calls for non-existing files.  KDE can do hundreds of access(2) calls
+to find one icon file.  In my example, just finding the mplayer icon
+required around 230 access(2) calls.</p>
 
 <p>The KDE code seem to search for icons using a list of icon
 directories, and the list of possible directories is large.  In
 (almost) each directory, it look for files ending in .png, .svgz, .svg
 and .xpm.  The result is a very slow KDE menu when /usr/ is NFS
-mounted, as showing a single sub menu result in thousands of NFS
+mounted.  Showing a single sub menu may result in thousands of NFS
 requests.  I am not the first one to discover this.  I found a
 <a href="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report
 from 2009</a> about this problem, and it is still unsolved.</p>