[Kde-pim] First step in making akonadi less ressource hungry

[Michael Jansen]

Hi

Currently akonadi uses some kind of broadcast to inform its
agents/resources/feeders about events. Everyone subscribes to
one signal NotificationManager::notifiy(...) and then receives every
single notification. It then decides itself if the item(s) involved is
interesting. If not it ignores the item.

Since there are quite some subscribers to that signal this means every
notifications wakes up more than 10 processes that probably only wake up
to ignore the notification.

What initially brought me to that problem is seeing the cpu load when
importing (synchronizing) a big maildir ressource the first time. At
that time plasma was really big in the midst of the running. But
currently it does not register with the messagesource so there is
probably something i either have to still port or there is another problem.

How to solve that problem. The first step is to separate the listeners
from the notification providers point of view. That's exactly what this
patch is about.

The notificationmanager now only provides two methods:

1. subscribe( identifier )
2. unsubscribe( identifier )

With those two methods anyone interested in Notifications can
subscibe/unsubscibe with the server. The first method returns a
QDBusObjectPath. The server registered a new Object there before
returning the path. Its of type MessageSource and provides currently
only two methods:

1. unsubscribe()
2. SIGNAL: notify()

The first is a convenience method, the second is the exact same signal
previously part of NotificationManager.

The patch does not yet solve the problem i explained above. It is just
the foundation for the solution. Now we have the possibility to let the
subsciber inform the server about the kind of items they are interested
in. The server would then first check that information and only emit the
signal for that particular subscriber if the subscriber told him it
wants to know about that item type (or told nothing at all).

That's where i need input. What kind of preselection makes sense and how
should we implements them?

I see

1. Select by mimetype
2. The invitation agent is only interestend in multipart messages. A
preselection here would make sense two because iiuc the agent has to ask
for the message before he is able to determine if it is a multipart message.
3. ????

For me the patch works but i'm not 100% entirely sure i catched every
possible subscriber. Are there apps subscribing that do not use Monitor ?

Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: akonadi.patch
Type: text/x-patch
Size: 13696 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100814/a4f7cbed/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdepimlibs.patch
Type: text/x-patch
Size: 10586 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100814/a4f7cbed/attachment-0001.bin>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/