GNOME Bugzilla – Bug 768766
base-item: Improve and simplify the tracking of the nie:DataSource
Last modified: 2018-01-23 10:05:11 UTC
We can be a bit clever in the way each BaseItem tracks its Source/nie:DataSource. Currently we keep a copy of the URN representing the nie:DataSource in Tracker as a string. Usually we will have a large number of BaseItems pointing to a small number of nie:DataSources. The URNs of these nie:DataSources look like: - gd:goa-account:account_1442355024_0 - urn:nepomuk:datasource:d289a99b2854ad9e9d19d497c112f6d9 This means that there will be several copies of a handful of strings. Memory is fragmented and wasted. Most of the time we want the online Source of the BaseItem, if any, and not the nie:DataSource's URN. It is unnecessary work to go via the SourceManager to resolve the URN. (Note that for online BaseItems, the Source:id is the same as the URN of the nie:DataSource, and are prefixed by "gd:goa-account:". This isn't true for local BaseItems because Tracker might have several local nie:DataSources, and the Source:id is "local".) Therefore, let's just keep a reference to the Source if the URN points to an online nie:DataSource, and a GQuark to track the URN itself. That means we replace a pointer and heap allocated string with two pointers and a 32-bit integer. Some sub-classes were using one of those two pointers anyway for the SourceManager [*]. We can't say how much memory or fragmentation we save without actual measurements, but it isn't any worse and it does simplify the rest of the code. The little extra work while reading the TrackerSparqlCursor data will be masked by the disk I/O and IPC involved. [*] I think we can avoid keeping a pointer to singletons for every instance by tracking them at the class-level. But, let's not bother about it in this bug.
Created attachment 331399 [details] [review] base-item: Simplify tracking the nie:DataSource
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-photos/issues/49.