[Kde-pim] Speed of storing large numbers of records, and sizes of akonadiserver and dbus-daemon
Shaheed Haque
srhaque at theiet.org
Sat Feb 25 21:18:28 GMT 2012
I decided to focus initially on the write to the database. The scenario is:
1. I have 473997 entries the collection. I remove the last two, and
force a "resume" to refetch them.
2. Getting the 2 entries from Exchange took 39 ms.
3. Writing them to Akonadi/pimitemtable took 193443 ms
4. Another 3939 ms to write an "I'm done" attribute to collectionattributetable.
Step 3 breaks down like this:
m_galItems.clear();
(get 2 items from Exchange)
(start timer)
Akonadi::ItemSync *job = new ItemSync(*m_gal);
connect(job, SIGNAL(result(KJob *)), SLOT(retrieveGALBatchDone(KJob *)));
job->setIncrementalSyncItems(m_galItems, Item::List());
...
(end timer in completion handler)
Now, the interesting thing is that while the ItemSync job is running,
the Debugger in Akonadiconsole goes mad. I have not yet managed to get
akonadconsole down from its 100% CPU 1.6GB (resident) high to be able
to examine the output in detail, but it looked as though every
existing record in the collection was being *fetched*. That is surely
wrong...any clues from the Akonadi folk as to what is going on? Or is
there something more I can do to pin this down?
Thanks, Shaheed
_______________________________________________
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/
More information about the kde-pim
mailing list