YDL 2.3 + KDE . . . . slow?

[Bill Fink]

On Wed Jul 10 2002, Ted Johansson wrote:

> I see the same things with YDL on my Imac DV/SE (450 MHz, 256 MB memory, =
> 20 GB=20
> HD). As an experienced rh-linux user (two pc:s already running rh7.3, hav=
> e=20
> used linux since RH4 and last year also SuSE), YDL was the choice when I=20
> converted the imac last week to unix. Therefore, I can not tell how previ=
> ous=20
> YDL behaved on the same hardware, just comparing the similar PC installat=
> ions=20
> (466 MHz PC/256 MB server and 800 MHz/256 MB portable)
> 
> Most things run OK, but something with KDE must be broken or really=20
> misconfigured, since the startup of Konqueror takes 30 seconds! There is =
> very=20
> little sign of disk activity, which should rule out low memory. The netwo=
> rk=20
> is correctly set up using AirPort, routing, resolv.conf, hosts etc. look=20
> similar as on the RH7.3 PC machines, DNS lookups (forward and backwards) =
> also=20
> work as they should.
> 
> I ran some tests on the 466 MHz PC and the 450 MHz imac:
> Konqueror=09=09PC=093 seconds=09=09Imac:=09=0930 seconds
> Mozilla=09=09PC=0911 seconds=09Imac:=09=0910 seconds.
> 
> Furthermore, ftp via Konqueror does not work (affects e.g. kpackage) - ca=
> n not=20
> connect to host computer. Ftp via mozilla does work.
> 
> What can be wrong???

Hi Ted,

I'm running a heavily modified YDL 2.1 system (2.4.19-pre8-ben0 kernel,
XFree86-4.2.0-0.6.24a, mozilla-1.0.0-9).  I just recently updated my
system from KDE 2.2.1 to 3.0.1.  After doing this I noticed via top
that I had a runaway kdeinit process (something having to do with style)
that was consuming all available CPU cycles.  Doing an strace on that
process showed it wasn't making any system calls, i.e. it was just
spinning forever in some tight CPU loop.  I killed that process and
the idle time went back up to 99% from essentially 0 before.  Being
somewhat concerned I rebooted, and was relieved to determine after
logging back into KDE that this weird problem did not reoccur.

I should mention that to be safe, before logging into KDE 3, I started
with all new .kde and related directories and files (I moved the old
directories and files out of the way).

To investigate why it was taking konqueror so long to startup, I did an
strace of starting konqueror.  After a bunch of activity it finally did:

...
stat("/me/bill/.kde/share/apps/konqueror/konqueror.rc", 0x7fffe658) = -1 ENOENT (No such file or directory)
stat("/usr/share/apps/konqueror/konqueror.rc", {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
stat("/me/bill/.kde/share/apps/konqueror.rc", 0x7fffe798) = -1 ENOENT (No such file or directory)
stat("/usr/share/apps/konqueror.rc", 0x7fffe798) = -1 ENOENT (No such file or directory)
open("/usr/share/apps/konqueror/konqueror.rc", O_RDONLY) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
SYS_197(0xb, 0x7fffe958, 0x7fffe958, 0x100ab4d0, 0x100ab7c0) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30058000
read(11, "<?xml version=\"1.0\"?>\n<!DOCTYPE "..., 4096) = 4096
read(11, "rue\" iconText=\"icontextright\" fu"..., 4096) = 229
close(11)                               = 0
munmap(0x30058000, 4096)                = 0
brk(0x100b6000)                         = 0x100b6000
brk(0x100b8000)                         = 0x100b8000
brk(0x100bb000)                         = 0x100bb000
brk(0x100c0000)                         = 0x100c0000

At this point it just waited for about 9 seconds.  Then there was a little
more activity followed by:

...
stat("/me/bill/.kde/share/apps/konqueror/konqueror.rc", 0x7fffe4c8) = -1 ENOENT (No such file or directory)
stat("/usr/share/apps/konqueror/konqueror.rc", {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
stat("/me/bill/.kde/share/apps/konqueror.rc", 0x7fffe608) = -1 ENOENT (No such file or directory)
stat("/usr/share/apps/konqueror.rc", 0x7fffe608) = -1 ENOENT (No such file or directory)
open("/usr/share/apps/konqueror/konqueror.rc", O_RDONLY) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
fstat(11, {st_mode=S_IFREG|0644, st_size=4325, ...}) = 0
SYS_197(0xb, 0x7fffe7c8, 0x7fffe7c8, 0x100ad360, 0x100be1e8) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x30058000
read(11, "<?xml version=\"1.0\"?>\n<!DOCTYPE "..., 4096) = 4096
read(11, "rue\" iconText=\"icontextright\" fu"..., 4096) = 229
close(11)                               = 0
munmap(0x30058000, 4096)                = 0

Here there was another delay of about 9 seconds.  These two delays of
9 seconds each for a total of 18 seconds account for most of the about
20 seconds it takes for konqueror to startup.  Checking ps during the
delays showed that konqueror was not waiting for anything but was in
a run state, basically just spinning its heels.

The above was on my home dual 500 MHz G4 system (which I run a UP kernel
on so it's effectively a single processor system).  I repeated this
experiment on one of my work 867 MHz G4 systems.  It behaved basically
the same except each of the two delays was only about 6 seconds for a
total delay of about 12 seconds.  It would appear that konqueror is
spinning in a tight loop for a fixed number of iterations through the
loop.  Thus if you're on a faster processor the loop iteration will
complete in a shorter period of time, and conversely if you're on a
slower process you will have a proportionally longer effective delay.
I would presume that the loop is checking some memory location that's
supposed to change but never does, so the loop has to complete all of
its iterations before falling out the bottom.

Other applications seem to load in reasonable amounts of time.  mozilla
starts up in about 3 seconds, kmail in about 6 seconds, a new konsole
only takes about 1 second, and the KDE Control Center loads in less
than 2 seconds.  These timings are all on my home dual 500 MHz G4 system.
Since I use mozilla rather than konqueror I'm fairly happy with KDE 3,
including using the Mosfet.org high performance Liquid KDE style engine.

One other unrelated problem I've encountered with KDE 3 is that none
of the KDE screensavers work (such as the Matrix screensaver) which
did work fine with KDE 2.2.  I've tracked this down to an apparent bug
with handling the names of the screensaver executables.  I'm guessing
that the high order bit of each character in the name is somehow getting
set, because when I do an strace of the KDE control center when I do a
test of for example the Matrix screensaver, instead of seeing an access
of /usr/bin/kmatrix.kss I see an access of /usr/bin/???????????, where
the number of '?' characters matches the number of characters in the
name kmatrix.kss (or similarly for other scrensavers).  I would like
to get the KDE screensavers working again but it's not a total showstopper
(you just get a black screen when you lock the screen instead of the
nice screensaver).

						-Regards

						-Bill