Open martin-ejdestig opened 5 years ago
The std::map could potentially be very large. Perhaps it is not a problem in practice due to IPC overhead overshadowing cost of copying. I think Glib::Variant* is reference counted so perhaps copying is negligible (GVariant definetely is, but not sure if Glibmm wrapped class does a deep copy of the underlying GVariant or not).
@mardy @kursatkobya @jonte Any experience with using signals with complex types and large values in the generator? Pondering if this is worth looking into or not.
Built Glibmm locally and Glib::VariantBase does this:
VariantBase::VariantBase(const VariantBase& src)
:
gobject_ ((src.gobject_) ? g_variant_ref_sink(src.gobject_) : nullptr)
{}
VariantBase& VariantBase::operator=(const VariantBase& src)
{
const auto new_gobject = (src.gobject_) ? g_variant_ref_sink(src.gobject_) : nullptr;
if(gobject_)
g_variant_unref(gobject_);
gobject_ = new_gobject;
return *this;
}
So cost of copying complex container types is reference counting on all elements. And in this particular case, copies of std::string (backing used for Glib::ustring) for the keys.
I'm always for optimizing :-)
But in this case I'm not sure we can: I don't see much room to improve the sub side, because it needs anyway to copy those values into the VariantBase
objects. But making the parameters const references does makes sense in any case.
As for the proxy side, yes, I think we can save a copy in the emission of the local signal if we mark its parameters to be const references.
Perhaps not that bad for a string, but e.g. have a signal that results in something like this in:
*_proxy.h:
*_proxy.cpp:Proxy::handle_signal():
*_stub.cpp:
Should perhaps add const & or && and std::move for non simple types where applicable.