[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Speed issues on app load
From:       rik () kde ! org
Date:       2000-12-20 20:43:10
[Download RAW message or body]


Observations on app loading speed:

* It takes 700ms to load and map a window with the most simple KDE application
  possible.

* It takes 10s to load and map konsole when it hasn't been used for a
  while.

* It takes 2s to load and map konsole when it's just been used.

The real problem here is the 10s loading for apps that haven't been
used for a while. It's just silly.

This isn't strictly a KDE problem but I think it's still worth
investigating, considering that it's only really KDE apps that have
this behaviour. I don't have any other apps that take so long to
load. Perhaps this is a Linux-only problem...

According to strace -r, a lot of time is spent in things like mmap
and mprotect stuff, which I think is shared libraries being mmap-ed,
but I don't think this is the only problem. It seems every single
font on my system (1662 total) is opened, so there's something up
with the X font loading there. I've reduced that by temporarily
disabling nearly all of my fonts.

Anyone care to guess how we can ask the system to be nice and load
apps faster ? All my shared libs and apps must have been through disk
cache at some point, and there's 91M of cache | 75M of buffers,
so I don't know if it's disk access that's the problem.

Here's the output of 'vmstat 1' as I start keditbookmarks:

  procs                      memory    swap          io     system         cpu
r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
0  0  0   7764  23240  79912 103572   0   0    11     6  151   178  26   4  70
0  0  0   7764  23236  79912 103572   0   0     0     0  108   749  5    1  94
( 'keditbookmarks\n' )
1  0  0   7764  22676  79912 103572   0   0     0    62  111    48  55   2  43
1  0  0   7764  21232  79912 103584   0   0     0     0  139  1047  95   5   0
0  0  0   7764  20668  79912 103584   0   0     0     0  196   509  18   7  75
0  0  0   7764  20668  79912 103584   0   0     0     0  106    30   0   2  98
0  0  0   7764  20668  79912 103584   0   0     0     0  103    31   0   2  98
0  0  0   7764  20668  79912 103584   0   0     0     2  105    18   0   2  98
0  0  0   7764  20668  79912 103584   0   0     0     0  103    21   0   2  98
1  0  0   7764  17852  79912 103620   0   0     0     0  103   573  86   7   7
0  0  0   7764  19532  79912 103640   0   0     0     0  106  1681  78   6 17
( window mapped )

And here's the output when starting it again, immediately afterwards:

  procs                      memory    swap          io     system         cpu
r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
0  0  0   7764  17612  79912 104472   0   0    11     6  151   178  26   4  70
0  0  0   7764  17600  79912 104472   0   0     0     0  146   307   4   1  95
( 'keditbookmarks\n' )
1  0  0   7764  16980  79912 104472   0   0     0     0  109   125  59   1  40
1  0  0   7764  15372  79912 104476   0   0     0     0  206  2549  90  10   0
( window mapped )

No significant disk activity. 7s extra time on the first attempt !

Thoughts and suggestions welcomed.

On a related note: I managed to reduce the 700ms startup time for the
most simple KDE app by 100ms by disabling XIM in Qt. I'm not sure what
Qt is doing. It looks to me like it's trying to contact an XIM server.
According to the XIM docs, if I'm using a simple language like en or de
(as opposed to Kanji) then it might be better to use XIM in-process via
library calls. I'm guessing that would remove the 100ms delay.

My box is a single Celeron 600, 256M RAM, one ATAPI disk running on ATA/66,
which according to hdparm gives 109Mb/sec buffer-cache reads and 23
Mb/sec buffered disk reads. ~170M of memory free. Kernel is Linux
2.2.17. Filesystems are all reiserfs using tea hash. None are close to
full. X is XFree86 from CVS. X drivers are stripped down to bare minimum
- i.e. only the driver for the card I own, no PEX or anything like that.
I'm the only user on the box.

Rik

[prev in list] [next in list] [prev in thread] [next in thread]