On Wed, 2007-02-14 at 18:22 +0100, Christian F.K. Schaller wrote: > People have mentioned Tracker on this mailing list and we do plan on > investigating using that as it would be a good solution to our problem.
great > We are though a little worried about performance of such a solution, not > because we know of any concrete performance hitches with Tracker, but > just a general worry that a generic all directory encompassing solution > might not give performance at a level acceptable to our users. optimal performance will depend on how your app deals with the data. if your app needs to download into memory all files + metadata in one go at startup into RAM (which is a bad design IMO) then yes performance might not be as good. However if you code your app to page results in chunks (IE show me the first 50 music files) then performance would become a non-issue as further chunks can be added asynchronously on a need to know basis. > From > experience I know that music player developers for instance are very > sensitive to how fast they are able to display items in your 10 000 song > collection and get the metadata from those songs onto the screen. There are workarounds here that can eliminate the bottlenecks (if what I said above is not desirable). One thing we are considering is having a flattened sqlite db for just music which tracker would maintain and keep up to date. This db can be read in-process by Rhythmbox and other apps and would eliminate the dbus scalability problems with transferring large data over the bus as well (in effect it would become a common music database). Apps would only need to listen to tracker to receive updates/additions/deletions (as only tracker should update the db) Also its only worth storing metadata here thats needed for display at startup (which in the case of a music player is probabaly six fields max) - the rest of the metadata can be gotten from tracker when needed (like in a properties dialog or when playing a track) as this is not a performance bottleneck. jamie. _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
