[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