Bug 227589

As I have quite some performance problems with sending mails in KMail: do you have another example which proofs that kwin is the culprit?

> even if compositing and desktop effects are disabled.
...kmails btw. sends fine for me ;-)

@axel:
for the beginnig, fire a konsole and run "top", watch what process drains your cpu

@axel: and if you're using oxygen widget style and decoration, try use another style, decoration (like e.g. a simple one. Say plastique, or clearlooks)

i have these performance problems too.
- i can confirm the problem with kmail
- a similar problem occurs when opening the filter menu, it takes very long 5-10 seconds until the menu appears, the also takes that long to update, when i switch between filters i wanted to edit.
- the problems occurs also in kopete, when i call the choose "change metacontact"
the problem also occurs with desktop effects disabled. 
 
https://bugs.kde.org/show_bug.cgi?id=200453
https://bugs.kde.org/show_bug.cgi?id=224037

i am not sure, if the bug is with kwin, but it would be really nice to be fixed. so far i do not receive any responses on my reports. the kmail bug at least is not as bad as before. sending now works, but very slow.

i have used top

i the case of kmail sending mails as well as opening the filter menu very slowly it is virtuoso-t and nepomukservices that drains the cpu power
in the case of my kopete example it is kopete itself.

I used top as well, normally Xorg and plasma-desktop use between 8-19% of he CPU (ThinkPad Z60m).
When sending mail, arkonadi and nepomuk slow it down even more.

Regarding widget style and decoration, I was using oxyglass, as the original oxygen desktop offered black fonts on black backgrounds in the taskbar, which was not really my favour ;-) I will look for your recommendation.

reassigning to nepomuk

if you're more interested in a fast system, call "kcmshell4 kcm_nepomuk" and uncheck database (and indexing)
then kill the nepomuk and virtuoso-t processes

(arch silently installed virtuoso 6.1, which is incompatible to 5.x used by nepomuk - thus nepomuk doesn't work here and anything runs fine ;-)

plasma has probably a constantly (full) repainting widget (the clock...) and this way triggers cpu load on X11 directly and inderectly (through compositing)

-> try to disable the seconds or use a smaller clock

it is a duplicate #219687

(In reply to comment #7)
> reassigning to nepomuk
> 
> if you're more interested in a fast system, call "kcmshell4 kcm_nepomuk" and
> uncheck database (and indexing)
> then kill the nepomuk and virtuoso-t processes

...in this case arkonadi complains about a non-running nepomuk

> (arch silently installed virtuoso 6.1, which is incompatible to 5.x used by
> nepomuk - thus nepomuk doesn't work here and anything runs fine ;-)

axel@z60m:~> zypper if virtuoso-server
Informationen für Paket virtuoso-server:

Repository: @System
Name: virtuoso-server
Version: 6.1.0-1.2
Arch: i586
Hersteller: openSUSE Build Service
Installiert: Ja

...

6.1 is installed by default, it does not seem that nepomuk complains about it....
 
> plasma has probably a constantly (full) repainting widget (the clock...) and
> this way triggers cpu load on X11 directly and inderectly (through compositing)
> 
> -> try to disable the seconds or use a smaller clock

That might be the system monitor (CPU, temperature, network)

> 6.1 is installed by default, it does not seem that nepomuk complains about
> it....
my bad - i had data from 5.x in ~/.kde/share/apps/nepomuk and instead 
converting it, virtuoso exits and nepomuk runs as stub.
now let's see what happens when i send this mail ;-)

hmmm... for the moment things behave nicely.
nepomuk & virtuoso took some cpu to build the database, but that's been it (i however don't use strigi - and don't intend ;-)

I use kontact on a remote machine via SSH and exported X-Windows. There are severe performance issues and one I noted was that even typing is getting slow at some moment. And just after that, I get the following messages in the konsole window that started kontact:
[/usr/bin/nepomukservicestub] void Soprano::Server::ServerCorePrivate::addConnection(Soprano::Server::ServerConnection*) New connection. New count: 16
[/usr/bin/nepomukservicestub] Soprano::ODBC::Connection::Connection() Soprano::Server::ServerConnection(0x7f69b0008170)
[/usr/bin/nepomukservicestub] virtual void Soprano::Server::ServerConnection::run() thread done.
[/usr/bin/nepomukservicestub] virtual Soprano::ODBC::Connection::~Connection() Soprano::Server::ServerConnection(0x7f69b0008170)
[/usr/bin/nepomukservicestub] void Soprano::Server::ServerCore::serverConnectionFinished()
[/usr/bin/nepomukservicestub] virtual Soprano::Server::ServerConnection::~ServerConnection() Removing connection
[akonadiserver] void Nepomuk::Search::QueryServiceClient::close()
[/usr/bin/nepomukservicestub] void Soprano::Server::ServerCore::serverConnectionFinished() Connection removed. Current count: 15

Just beforehand, the kmail freezes for about 3-4 seconds and then works again. This is on KDE 4.5.2 on OpenSuse 11.2

Also remote windows are not as responsive as they used to be in KDE 4.3 let alone (instant reaction) in KDE 3.5 over my 100MBit/s link.

Being directly on the computer helps a bit, but there is still a lag sometimes, but it is not as strong. So I think kmail is waiting for nepomuk to do something and nepomuk has lost connection and re-establishes that connection which takes a long time for UI time counts...

This report is too old to be useful. Please, retest with KDE 4.8 Beta and all current packages; I'm not seeing performance issues anymore. Otherwise, please, close this as RESOLVED/FIXED (since there were serious problems and they were indeed fixed)

I think it is a good idea to close the bug. The real discussion should be on nepomuk and filewatchers. My 4.7.3 is almost unusable for the first 5 minutes after boot because it installs the filewatchers and because it loads semantic information via virtuoso-t startup. Same goes for strigi. I use recoll as an alternative and that allows me to index things over night instead of draining the performance of my computer while I need the full power or while I'm on batteries. There are performance issues, but also usability issues and I encourage us all to continue to contribute bug reports. Some of it is rather a whishlist that will probably ignored by the devs.

Closed as outdated.

Please keep your frustration about other components out of the bugreports. It is irrelevant to kwin and just causes frustration for those who have to use the bugtracker. Thanks.

Mea culpa - i forgot to reset the default assignee...

Too old, plus it seems like the issue has been fixed.

My issue was fixed in 4.7.4 (opensuse 12.1) but it appears differently in 4.8.2 now. So ok to close that bug. I think this was related to virtuoso and nepomuk issues.