From dc5fd4f15e2f5d3aeb656fe1f8dce65deaae9f47 Mon Sep 17 00:00:00 2001 From: Niels De Graef Date: Sun, 29 May 2022 13:47:01 +0200 Subject: [PATCH] channel-map: Don't specify default c_marshaller Apart from being less code, this actually gives us a tiny performance improvement. Up until a few years ago, if you pass `NULL` as the marshaller for a signal, GLib would fall back to `g_cclosure_marshal_generic` which uses libffi to pack/unpack its arguments. One could avoid this by specifying a more specific marshaller which would then be used to immediately pack and unpack into GValues with the correct type. Lately however, as a way of optimizing signal emission (which can be quite expensive), GLib added a possibility to set a `va_marshaller`, which skips the unnecessary GValue packing and unpacking and just uses a valist variant. Since the performance difference is big enough, if the marshaller argument is NULL, `g_signal_new()` will now check for the simple marshallers (return type NONE and a single argument) and set both the generic and the valist marshaller. In other words, less code for us with behind-the-scenes optimizations. In case you also want va_marshallers for more complex signals, you can use `g_signal_set_va_marshaller()`. --- gvc-channel-map.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/gvc-channel-map.c b/gvc-channel-map.c index bf4d737..688a451 100644 --- a/gvc-channel-map.c +++ b/gvc-channel-map.c @@ -166,8 +166,7 @@ gvc_channel_map_class_init (GvcChannelMapClass *klass) G_TYPE_FROM_CLASS (klass), G_SIGNAL_RUN_LAST, G_STRUCT_OFFSET (GvcChannelMapClass, volume_changed), - NULL, NULL, - g_cclosure_marshal_VOID__BOOLEAN, + NULL, NULL, NULL, G_TYPE_NONE, 1, G_TYPE_BOOLEAN); }