Yes, I do get quite a few duplicates when running Akregator (or perhaps it's Korganizer, which has a remote resource) in the background.

I haven't posted again as I've been running it for almost a week now with no slowdown. I'm almost confident now that the reason was due to having oxygen animations enabled. I will continue to run and 'up' my usage by running a few apps in the background at all times (been rather dormant this week as I have mock exams) and see how it fares.

Will update then with more exmap info.

Updated statistics after 6 days of average usage - then closing all applications:

http://wipup.org/updates/view/78

Any tips?

Both KWin and KNotify4 in this case look to be a touch high on the memory usage side. Does restarting them reduce their usage?

For KWin, the kquitapp should work, for knotify4 just kill it.

Are you saying it's natural for virtuoso (when not indexing) or kopete to take up in excess of 40M?

Anyways the standard I do at this stage is to swapoff -a then swapon -a, then relogin. It makes it quite snappy again. But not perfectly snappy as a fresh boot.

For virtuoso, it probably is, since it uses memory as set in System Settings > Advanced > Desktop Search. For Kopete, that is probably a little on the high side, but not as bad as KWin or KNotify4 which both look like leaks...

I notice that whenever I try to open the settings dialog in Kopete (Settings->Configure) a window opens but there's nothing in it. Kopete hangs and I have to kill it. Perhaps related somehow?

(very annoying, by the way)

That is very likely related and shouldn't occur. If you can start it from Konsole, try looking to see what the last few lines output are.

Fresh Kopete, first thing is tried to open settings dialog. I've annotated the paste so you know the sequence of events.

Code: Select all

dion@epicbox ~ $ kopete
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kopete(11147)/kio (KDirWatch) KDirWatchPrivate::removeEntry: doesn't know "/home/dion/.kde4/share/apps/kabc"
Calling appendChild() on a null node does nothing.
Calling appendChild() on a null node does nothing.
Calling appendChild() on a null node does nothing.
// Note: at this point I opened the dialog
VIDIOC_ENUMSTD: Invalid argument
VIDIOC_ENUM_FMT: Invalid argument
VIDIOC_ENUMSTD: Invalid argument
VIDIOC_ENUM_FMT: Invalid argument
QObject::connect: Cannot connect (null)::onlineStatusChanged(Kopete::Contact *, const Kopete::OnlineStatus &, const Kopete::OnlineStatus &) to Kopete::Identity::updateOnlineStatus()
// It has now hung and I need to kill it.

Same occurs when running as root or a fresh user.

I suspect this is caused by the video4linux errors... do you have a webcam connected?

When it is hung, try attaching gdb to it and generating a backtrace ( enter "bt" ).

Code: Select all

gdb -p $(pidof kopete)

Not on it right now but yes this laptop has a webcam and I've never been able to get it working properly for more than a minute.

That is likely the cause of your inability to open the control modules, since Kopete will try to interact with it, causing an I/O deadlock.

Is there a way to disable it completely?

Other than pinpointing the module responsible for configuring webcams and disabling that by breaking its configuration, no...

Hum - magically started working after a reboot.

Anyways things have gotten slow again, even though not touching KMail at all (using webbased frontend) and nor akregator. Here are exmap statistics. Still believe something is misbehaving.

http://wipup.org/updates/view/94

It could also be caused by usage of graphics memory, which would cause slowness if data has to be removed for new data to be added.

I don't think the slowness can be attributed to memory usage in this case however.