Bug 276620 - Mark EMail Actions spikes Virtuoso CPU usage
Summary: Mark EMail Actions spikes Virtuoso CPU usage
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Nepomuk Feeder Agents (show other bugs)
Version: 4.6
Platform: Microsoft Windows Microsoft Windows
: HI normal
Target Milestone: ---
Assignee: Tobias Koenig
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-27 15:59 UTC by Andre Heinecke
Modified: 2015-03-17 12:39 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
CPU Usage after mark as read (41.98 KB, image/png)
2011-06-27 15:59 UTC, Andre Heinecke
Details
Debugoutput during the mark (57.45 KB, text/plain)
2011-06-27 16:00 UTC, Andre Heinecke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Heinecke 2011-06-27 15:59:42 UTC
Created attachment 61371 [details]
CPU Usage after mark as read

Version:           4.6 (using KDE 4.6.4) 
OS:                MS Windows

When you select several emails and do a action like "Mark Mails as Read / Mark Mails as Unread" etc. you get an extreme spike in CPU usage of Virtuoso while akonadi_nepomuk_email_feeder produces loads of debug output.
Test was with 500 Mails and took ~60 secons high 
During this time my hard disk was also working on its limit.

Attached is a screenshot of the cpu usage (grid x axis is 5 seconds) and the unshortened debug output created during this action.

Reproducible: Always

Steps to Reproduce:
1. Select ~500 Mails
2. Mark Mail as read / unread


Actual Results:  
CPU usage and Disk IO Spikes. For 60-100 seconds in my tests, i guess this will depend on your machine.

Expected Results:  
Marking some hundred mails with a tag/flag should not take several minutes.
Comment 1 Andre Heinecke 2011-06-27 16:00:06 UTC
Created attachment 61372 [details]
Debugoutput during the mark
Comment 2 S. Burmeister 2011-06-28 08:20:45 UTC
same here. neopmuk keeps akonadi busy doing full payload fetches for a lot of actions within kmail and thus slowing down the whole desktop and kontact in special.
Comment 3 Christophe Marin 2011-07-01 10:27:39 UTC
This bug doesn't deserve the major severity.
Comment 4 Bernhard E. Reiter 2011-07-01 10:59:37 UTC
I think it does deserve major severity because it makes
Kontact on Windows a lot less usable. It has a major impact on usability,
as far as I can tell right now.
Comment 5 Christophe Marin 2011-07-01 11:37:51 UTC
major means "major loss of function". Being slow doesn't enter that category.

Please read https://bugs.kde.org/page.cgi?id=fields.html#bug_severity
Comment 6 Bernhard E. Reiter 2011-07-01 14:59:16 UTC
Being so slow that users refrain from using it, would in my view qualify
as a "major loss" of an important proptery. But of course I cannot be sure
that this issues is the only cause, so maybe "major" it too early to tell.
Comment 7 Vishesh Handa 2013-08-17 12:21:39 UTC
This bug is still somewhat present in 4.11. The main issue is that when an email is marked as read the email is reindexed. This is done by throwing away the old data and indexing the data from scratch. Ideally one should just update the flags that have changed, unfortunately that is a little hard.

It's simple to change the isRead flag, but the other flags which indicate if the email has been marked as important/spam/sent/etc are saved as tags. We cannot just remove the old tags and add the new ones as that discards any tags that a user might have tagged an email with.

The proper solution would be only to remove the tags added by the feeder and to update them accordingly. This solution is a lot more complex and therefore has not been implemented by anyone.

Anyway, email indexing is much faster with 4.11 so the cpu spikes should be less noticeable. I'm leaving this bug as open until someone implements proper indexing of the changes.
Comment 8 Vishesh Handa 2015-03-17 12:39:23 UTC
The Nepomuk project is no longer maintained in KDE since 4.13. For email indexing, Baloo provided an Akonadi resource to index emails, contacts and events. Tags are now maintained by Akonadi itself.