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 > hat: > > * Just trying to figure out right now if it is acceptable that the > save request reports "finished" before contacts are (fully?) > indexed. > * 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. Cheers, Philip -- Philip Van Hoof freelance software developer Codeminded BVBA - http://codeminded.be _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
