Amarok's weight will be reduced hopefully when it switches to the Smoke based QtScript bindings as the current QtScriptGenerator bindings are horribly inefficient with memory.

KRunner can be fixed by using only the runners you need. If you find a particular runner wastes memory, please file a bug report.

Fixing the application which excessively spawns kio_trash would help also. Grepping ~/.xsession-errors for " Killing update job for "trash:/"" may help reveal the culprit, with the KIO debugging area enabled. KRunner does this intensively.

Akonadi simply shouldn't have been using 200MB. If a particular resource was doing this, please file a bug.

OK - ignoring Amarok's issue for the moment even when not touching Amarok it's still rather slow.
I have removed all of Akonadi's resources and started completely fresh.

Code: Select all

dion@epicbox ~ $ ./memory.sh | grep akonadi
20837  159816K   akonadi_control
20884  269236K   akonadi_maildis
20879  273484K   akonadi_contact
20880  273484K   akonadi_contact
20883  277684K   akonadi_maildir
20885  283372K   akonadi_nepomuk
20881  294848K   akonadi_ical_re
20882  294848K   akonadi_ical_re
20889  306184K   akonadi_vcard_r
20839  333880K   akonadiserver

All of the "trash:/"'s in xsession-errors are all caused by krunner.

Make sure to use a utility such as exmap, which accurately measures memory usage.

OK I've been using Fluxbox for the past 3 days with KDE applications running on top - notably Kopete, Akregator, KMail, Korganizer, Amarok, Blogilo, Dolphin and also system apps like KMix and Krunner.

I haven't noticed a single bit of slowdown. Everything is just so blazing fast. Browsing and scrolling in dolphin is instantaneous.

I've got conky running and from the stats even though CPU % is considerably lower and less jumpy (in KDE it's also very low when idle but jumps up very quickly to high levels when doing things such as up to 70%, whereas Fluxbox keeps it in general below 30% at all times and 1% when idle). Looking at swap usage it's identical. Also looking at physical RAM usage it's also identical in all respects. Here's a dump from free -m:

Code: Select all

dion@epicbox ~ $ free -m
             total       used       free     shared    buffers     cached
Mem:          1753       1602        151          0        100        592
-/+ buffers/cache:        909        843
Swap:          494         27        466

So I'm really not quite sure what to make of it. The only difference I can make out is that Nepomuk/Strigi isn't running and there's no compositing. However I seem to recall turning off compositing and Nepomuk not making any difference in KDE.

Any insights from more experienced folks on what could be causing the slowdown?

The only two applications which are a major part of the workspace you are missing are Plasma and KWin, thus the slowdown must be caused by one of them.

There was a short time when there was a memory leak in krunner, I believe. Slowness was one of the symptoms. This seems to have been cured now, but it's worth checking that you haven't missed any updates.

Given that KRunner was perfectly fine in Fluxbox suggests that any KRunner-related problems must be KRunner+Nepomuk problems, because Nepomuk wasn't on with Fluxbox.

I'm back on KDE now and with some testing I _think_ I've found the culprit - it could be the Oxygen widget style. On Fluxbox I switched to Skulpture to better match the rest of the desktop experience (clear-cut lines and so on) and now when using Skulpture I'm noticing minimal if no lag at all. Another tip which really sped things up in Dolphin was to make the icons bigger then increase the grid spacing between icons. If I put my mouse in the grid spacing and scrolled it would be very fast but when hovering over icons it became noticeably slower - likely due to the Oxygen hover effect (note: I turned off the information panel already). With Skulpture it also slows down slightly but not as bad as the Oxygen widget style.

... still investigating but at least KDE is usable again with those modifications.

I found that I could crash KRunner if I was too quick on the trigger. If I selected an entry while it was still listing possibilities, it crashed. That hasn't happened for some time now, so either I've adjusted to it without realising it, or it is cured.

If you feel fairly sure that the widget style is slowing things down, that should be reported.

I tend to use small icons and large spacing in dolphin. I hadn't really thought about it, but I'm sure you are right. It would seem reasonable, too. If you are scrolling over the icons it will be activating the info gathering for each icon you touch.

I will report it as soon as I try to isolate other probable causes through the next few days.

Any ideas what sort of data I can use to help the developers? Surely a bugreport saying "Oxygen widget style causes lag" isn't exactly helpful.

Just the other day I found my old laptop with only 1GB RAM (this one has 2GB) - and booted it up. It had KDE 4.1 installed on it, compositing wasn't enabled and neither was Nepomuk. I started up all my PIM apps and the memory usage only went up to about 400MB. Here on my supposedly faster, graphically more capable laptop, even with compositing and Nepomuk disabled just after logging in I'm already at 450MB. Regularly I'm around 600-800MB with all my PIM apps.

So I pitted it against my older laptop both with no Nepomuk and no compositing and quite honestly my newer computer is _slower_ or just at the same speed (not by a huge amount, but you can still notice). I'd have expected it to be much faster. Something tells me this just is not right at all. What sort of cruft went in between 4.1 and 4.4?

Oh, and my older laptop was using the Oxygen widget style.

Edit: here are some statistics. All are using `free -m`

New computer 2GB RAM, better NVIDIA graphics card. AMD64

Just after bootup and login into KDE 4.4:

Code: Select all

             total       used       free     shared    buffers     cached
Mem:          1753        560       1193          0         14        234
-/+ buffers/cache:        311       1441
Swap:          494          0        494

Opened Kopete. Didn't even log into any IM network. Nothing else yet open:

Code: Select all

             total       used       free     shared    buffers     cached
Mem:          1753        642       1111          0         24        260
-/+ buffers/cache:        357       1396
Swap:          494          0        494

Opened Firefox. Haven't yet navigated to any web page:

Code: Select all

             total       used       free     shared    buffers     cached
Mem:          1753        728       1025          0         25        294
-/+ buffers/cache:        409       1344
Swap:          494          0        494

Went to the KDE Forums:

Code: Select all

             total       used       free     shared    buffers     cached
Mem:          1753        760        993          0         25        304
-/+ buffers/cache:        430       1323
Swap:          494          0        494

Old computer. 1GB RAM. **** NVIDIA graphics card. x86.

Login. Opened Kopete. Opened Dolphin and browsed around. Opened Korganizer, KMail, Akregator, KJots and KTodo. Opened system settings. Opened Konsole. Looked at a few pictures with Gwenview. Edited a few files with KWrite.

Code: Select all

             total       used       free     shared    buffers     cached
Mem:          1247        449        797          0         20        191
-/+ buffers/cache:        237       1009
Swap:          494          0        494

Now correct me if I'm wrong, but something definitely isn't right.

Whilst Nepomuk can be expected to add some memory usage as it adds quite a few features ( or at least will once finished... ) Akonadi shouldn't cause that much of an increase...

Could you please use Exmap to determine which of the applications are causing the increase in resource utilisation? Note that the increased "slowness" of KDE 4.4 may be due to the new animations in the Oxygen style ( these can be disabled in System Settings )

I have disabled the GUI animations of the Oxygen style. Now it's gone to the usable state of the Skulpture design.

Here are the results of exmap - I'm going to leave somebody who's better at analysing this sort of stuff to comment and infer stuff.

Just after logging into KDE: http://wipup.org/updates/view/45/
After opening a bunch of applications: http://wipup.org/updates/view/46

Edit: exmap was run as root.

Any insights? Note: after opening the bunch of applications it wasn't "slow" so to speak. But I can guarantee after a day's worth of using it it's going to slow down a tad. Plus I think now the issue is why my older laptop can enjoy such thrifty use of memory (from what vague free -m reports I found) where this laptop seems to enjoy putting itself under stress.

The Exmap results from running for a day would be more interesting. Note that the "Effective Mapped" column is the most correct for measuring memory usage.

Note that virtuoso-t is the 8th heaviest process on my system, below the system wide mysqld.

Can you check your system monitor and see how many duplicate instances of various programs you have loaded? Ever since I upgraded to KDE 4.4 my system monitor keeps revealing tons of entries called kio_http. Terminating those causes the system to load a few and then over time it will again begin to build up on its own. They take 16mb of ram each. What is your free mem like when the slow down occurs?

As I stated in a other topic, please make sure to use a reliable utility to measure memory usage such as Exmap or KSysGuard.

Also, kio_http only runs because an application you are using requests a HTTP resource. This is probably caused by Akregator or Konqueror. Note that some applications don't clean up properly and their KIO slaves are left running until the application is closed.