Cache costly objects and D-Bus proxies

Georges Basile Stavracas Netorequested to merge
gbsneto/object-storage into master

I'm opening this MR for discussion of the design of the new object cache feature, that is a pre-requisite of the dynamic panels feature.

This MR introduces a new application-wide object cache, and adapt panels to use this cache to load expensive objects (such as D-Bus proxies and clients).

Code Architecture

  • The CcObjectStorage code has a singleton instance that is private to the API. No section of the code uses CcObjectStorage* directly. The instance is initialized using a memory barries to guarantee uniqueness.

  • The object storage code is not multi-thread safe, and must not be used off the main thread.

  • Since creating D-Bus proxies from bus, synchronously or asynchronously, is such a common operation, D-Bus-specific utility methods were crafted. They significantly reduce the diffs - in most cases, the commit diffs are +X/-X, since they just need to replace the g_dbus_proxy_new_from_bus{,_sync}() calls by cc_object_storage_create_dbus_proxy{,_sync}() calls.

  • The code has a series of assertions, to reflect the strict usage rules of the object cache. It is forbidden to retrieve an object that was not added, and to add an object that was already added. This is to ensure that we create a single instance, and only one instance, of each object. These rules will largely facilitate the dynamic panels work.

Testing

You can compare this work with the following steps:

  1. Run GNOME Settings
  2. Switch between panels

Expected Result: the first loading time of the panels is likely to be the same as before, but subsequent openings should be faster. Panels that use the same kind of objects (e.g. Wi-Fi, Network and Power panels use NMClient) should also reduce their loading times.

Blockers: the commits in this MR must not introduce crashes in the code. Subtle behavior changes can be fixed by subsequent patches, but if any of them are found during the testing phase, it should be fixed before merge.

To Do

  • Add profiling data
    • Measure performance improvements before and after the cache
  • Remove cache on objects that don't benefit from it, nor require it

CC: @felipeborges @hadess @carlosg @mkasik @hughsie @bberg

Issue: #35 (closed)

Edited by Georges Basile Stavracas Neto

Merge request reports