On Tue, 2011-03-15 at 09:33 +0200, Adrien Bustany wrote: > On Tue, 15 Mar 2011 08:10:18 +0100, Ville M. Vainio wrote:
Hey Adrien, and Hey Ville M. Vainio, > > On Mon, Mar 14, 2011 at 9:20 PM, Patrick Ohly > > <[email protected]> wrote: > >> I've said before and I say it again here, I consider performance > >> comparisons pointless at this time. > > > > Considering that e-d-s has a much more modest feature set than > > tracker (tracker in general being a much more ambitious project), I would > > have expected it to to trounce tracker in performance, which doesn't seem > > to be the case. I share the exact same opinion. I'd also like to point out, in defense of "Evolution UI was running, this creates load on the E-D-S store" that Tracker's RDF store has a direct-access method for opening the database by clients due to its use of SQLite's WAL journaling mode. This means that when a direct-access - enabled Tracker client reads from the database, it doesn't disturb the tracker-store process directly (only indirectly due to scheduling, but with process priorities in Linux also this can be completely avoided). GraphUpdated can be used in combination with Tracker's direct-access mode. You get GraphUpdated about data deltas post the transaction commit, so with SQLite WAL it's then available everywhere. On the subject process priorities: SCHED_IDLE vs. SCHED_FIFO; with direct-access you'll have it and you wont have to worry about the process priority of the service tracker-store. This of course depends on your process *having* access to meta.db (as I mentioned in another E-mail can Aegis on Harmattan prevent you from having access to meta.db, meaning that you must go over a IPC with tracker-store to do read queries too). This IPC then uses FD passing over D-Bus. > > This evidence might prompt to re-evaluate this part of the > > architectural plans. Or at least leave the door open to transitioning > > back to tracker when it's feasible. > > If you're interested in the saving performance of both solutions, I > answered the thread on the Tracker ML (didn't want to cross-spam > Meego-Dev). If you abstract the fact that EDS has no batching API (and > therefore seems to issue a fsync after saving each contact) by running > it over libeatmydata, EDS is approximately twice faster than > qtcontacts-tracker (though that area is being optimized currently). I > haven't done any contact fetching benchmarks. Note that it looks like you have e_book_add_contacts, commit_contacts and remove_contacts. Those look like batch APIs to me. However, in the example that I made for Tracker, I also didn't use Tracker's batch APIs BatchSparqlUpdate() nor did I use its UpdateArray(). BatchSpaqlUpdate() is mostly about prioritization, UpdateArray() is mostly about reducing D-Bus traffic. I think it's interesting to explain Tracker's fsync() behaviour of its RDF store: Because we believe that fsync() is only necessary to avoid data loss in case of an unclean shutdown of the system (when the filesystem isn't unmounted but the power is cut nonetheless), we only do fsync() and only on our journal file in case an application calls the Resources.Sync() D-Bus call. We also open our SQLite db in a specific way. Our SQLite database is always opened using: PRAGMA synchronous = OFF PRAGMA count_changes = 0 PRAGMA temp_store = FILE PRAGMA auto_vacuum = 0 PRAGMA encoding = "UTF-8" PRAGMA journal_mode = WAL http://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-db-manager.c#n214 With synchronous = OFF wont SQLite do any such fsync() call. This is OK because we do our own persistent journaling: http://git.gnome.org/browse/tracker/tree/src/libtracker-data/tracker-db-journal.c Doing an fsync() on a high-latency device like many nand and flash disks are, is a very big contributor to ie. reduced UI responsiveness. A monitor application that sees that the battery-bay is being opened can for example call the Resources.Sync() D-Bus call as soon as possible. For devices that do a clean emergency shutdown on critical battery, but where the battery can't be touched unless you void warranty of the device, this isn't needed (at least theoretically: a crasher bug being the exception here). 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
