[Meego-architecture] [MeeGo-dev] Some architecture changes (MSSF / Buteo / PIM storage)
Philip Van Hoof
philip at codeminded.be
Tue Mar 8 03:06:43 PST 2011
On Tue, 2011-03-08 at 11:56 +0100, Mathias Hasselmann wrote:
> Am Dienstag, den 08.03.2011, 12:41 +0200 schrieb Vitaly Repin:
> > > you seem to be proud of 80 seconds for 500 people.... I would absolutely
> > > not be proud about such
> > > a abysmal number.
> > Completely agree. The contacts sync speed should be increased.
> Yes, it's still far from optimal. Still we have some more rabbits in our
> * Just trying to figure out right now if it is acceptable that the
> save request reports "finished" before contacts are (fully?)
> * The tracker guys just investigate some more crazy tricks to
> improve update performance. Doubt many other people ever having
> driven sqlite optimization as far as the tracker guys are doing.
One of the problems is that the contact-updates also need to first
DELETE possible existing data. This often doubles the time to update.
We plan to add a Tracker-specific extension to SPARQL Update that allows
for UPDATE queries. Although with RDF ain't UPDATE queries going to look
nice (multivalue properties, etc). If you have syntax suggestions for
UPDATE for SPARQL, let us know.
A problem of DELETE could be that triples are removed one by one. I'm
today looking into trying to merge deletes together. Not sure yet if it
will help a lot as it's deleted by ID, which is the primary key =
indexed) and because SQLite deletes rows one by one (internally) anyway.
When a DELETE is very slow then note that the WHERE part of the DELETE
is more or less a SELECT to get the triples-to-delete. If that SELECT is
slow due to a full table scan, use of optionals (left joins), etc (the
usual things for SELECT) then the DELETE will also be slow, of course.
Philip Van Hoof
freelance software developer
Codeminded BVBA - http://codeminded.be
More information about the MeeGo-architecture