Shyru's World

Monday, September 25, 2006

aKademy 2006: Performance techniques

This talk was held by our optimizer, Lubos Lunak.

KDE Performance
  • Is not that good
  • Windows 95 is so much faster
  • and dont let me get started on JetPac

As you see we have to compare us with something of our power:

Is not that bad either
  • we are not noiceable worse thatn comparable competition
  • in fact, we are even often better
  • theres incomparable competition

So, no need to be very nervous, but we can still improve

KDE's performance is bad because:
  • Some libraries we use are bad
  • dynamic linker (shared libs) is bad (prelinking does not help much)
  • I/O performance is bad
  • really stupid mistakes are bad (e.g. he noticed that kicker would easily use 16 MB of memory, then he found out that the pager which could show the background in the pager cashed all background images in the original size, not the scaled down size)
  • many small things add up
  • nice things are sometimes not fast (kconfig is nice, but it is rather slow to parse all the text-files)
  • unneeded things are done (sometime ago kate created the find and replace dialog on startup)
  • initial resource usage is large because our framework is large (libraries, but that pays off when you start more applications)

What to do
  • find the problem
  • analyze the problem
  • do NOT guess
  • measure
  • verify assumptions
  • speed: cachegrind, sysprof
  • memory: exmap, xrestop, kmtrace
  • fix the problem

On-demand initializtion

Don't do the same ting over and over again. Save the result somewhere, check that the input hasnt changed. (e.g ksycoca)
We do many things during startup of every kde application:
kconfig, qsettings are rather inefficient, some things are repeated by every application.
Bottom line: We need to make more use of caching!

I/O performance #1
Time for this years quiz:

Which is faster?

=> Disk seeks are very slow (~10ms for every seek)

I/O performance #2
  • Try to avoid many small files
  • create single cache file at build time
  • create a single cache file at runtime
  • dont forget watching for changes
  • on demand loading (konsole is loading all color-schemes on startup, although that would not be neccessary)
  • kernel could(?) help

Other tips: Cheat! - Seriously :) Show progress (use a splashscreen, show messages or whatever), provide early feedback, optimize the common case, optimize big bottlenecks.

Many small things add up, we are large and complex.
Hundred times nothing tormented the donkey to death
"slovak proverb"
Time goes on,this kde wil never rund on 16 MB RAM.
We need to compare with comparable competition (We are never a match for xedit or WindowMaker)
We have to live with that. There is a limit that cannot reasonably be reached without significantly reducing features. We could cut the things that slow us down, but would have to sacrifice many features.
Would that be still KDE?

Some question which where raised afterwards:
Question: When we switch to SVG-icons, how can we make sure that the performance stays ok?
Answer: We need to cache the generated pngs and probably put them into one big file, to improve the "many small files" situation. (Gnome already does that).
Someone talks about using the Qt Resource system to load arbitrary data (like icons etc.) into one library and then have the kde4 application link to that and get the whole data faster, because it should already be in memory. Lubus Lunak did not like that idea that much because of the overhead of a library. He prefers to create specialized cache files, and that should be even faster.

Personal comment: This was very interesting, and i hope that KDE4 can do something in the "many small files"-area, and create cache files containing all icons of the current icon set, or caching the configuration of the user into one big file, etc.


Post a Comment

<< Home