High CPU usage in tray module

[12101111]

Waybar/src/modules/sni/item.cpp

Lines 169 to 176 in d08fbb2

	for (const auto& [name, value] : properties) {
	Glib::VariantBase old_value;
	proxy_->get_cached_property(old_value, name);
	if (!old_value || !value.equal(old_value)) {
	proxy_->set_cached_property(name, value);
	setProperty(name, const_cast<Glib::VariantBase&>(value));
	}
	}

This is caused by value.equal(old_value).Maybe an upstream issue, the implement of g_variant_equal is compare them by their pretty-printing string, which use many CPU cycles.(This is the source code: https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gvariant.c#L2736)

I remove this compare and the CPU usage reduce nearly to zero:

    for (const auto& [name, value] : properties) {
        proxy_->set_cached_property(name, value);
        setProperty(name, const_cast<Glib::VariantBase&>(value));
    }

( But this give me a lot warning : [2021-06-22 23:58:50.837] [warning] Failed to set tray item property: Fcitx.WindowId, value = 0, err = std::bad_cast )

[alebastr]

Hm... With all the quirks of various SNI client implementations that was the most compatible way of writing this, so I'd like to preserve the current logic.
Following patch should solve the pretty-printing:

diff

--- a/src/modules/sni/item.cpp
+++ b/src/modules/sni/item.cpp
@@ -68,6 +68,7 @@ void Item::proxyReady(Glib::RefPtr<Gio::AsyncResult>& result) {
     for (const auto& name : cached_properties) {
       Glib::VariantBase value;
       this->proxy_->get_cached_property(value, name);
+      value.is_normal_form();
       setProperty(name, value);
     }

@@ -165,6 +166,7 @@ void Item::processUpdatedProperties(Glib::RefPtr<Gio::AsyncResult>& _result) {
     auto properties = properties_variant.get();

     for (const auto& [name, value] : properties) {
+      value.is_normal_form();
       Glib::VariantBase old_value;
       proxy_->get_cached_property(old_value, name);
       if (!old_value || !value.equal(old_value)) {

Another option is to infer changed properties from signals and update those unconditionally. I have a rough draft at alebastr@7fd1566, but it has way too much string comparisons to my taste.

I did not get to profile any of those though. Would appreciate if you can try and compare both.