So I added some debugging output to dbus. When it peaked, it spent over a third of the CPU entirely in get_recipients_from_list(). (This is dbus checking if an incoming signal matches any of the rules added by org.freedesktop.DBus.AddMatch -- i.e. signal subscriptions. It does this for every rule, for every connection.)
So we can reduce the time spent there by being more efficient, by reducing the number of subscriptions, or reducing the number of signals.
Looking at which rules it's checking, the majority are subscriptions on NetworkManager. One per access point, one per device, from multiple connections. Could connectivity-cpp be a bit too subscription-greedy?
I'm not sure that get_recipients_from_list is the only (or worst) culprit here. Just something I noticed.
So I added some debugging output to dbus. When it peaked, it spent over a third of the CPU entirely in get_recipients_ from_list( ). (This is dbus checking if an incoming signal matches any of the rules added by org.freedesktop .DBus.AddMatch -- i.e. signal subscriptions. It does this for every rule, for every connection.)
So we can reduce the time spent there by being more efficient, by reducing the number of subscriptions, or reducing the number of signals.
Looking at which rules it's checking, the majority are subscriptions on NetworkManager. One per access point, one per device, from multiple connections. Could connectivity-cpp be a bit too subscription- greedy?
I'm not sure that get_recipients_ from_list is the only (or worst) culprit here. Just something I noticed.