Skip to content

menutracker: reduce allocations and signal emission

When handling action-added callbacks the code was previously using a freeze_notify/thaw_notify in all cases. This turns out to allocate a significant amount of memory when called a lot.

That said, it shouldn't be getting called this much but given the current state of affairs elsewhere in GtkActionMuxer, this brought temporary allocations down from 9MiB to 9KiB in gnome-text-editor after showing the context menu a few times.

Related #4422 (closed)

Before

    ALLOCATED      TOTAL    FUNCTION
[     9.5 MiB] [  22.76%]    gtk_action_muxer_action_added
[     9.5 MiB] [  22.75%]      gtk_menu_tracker_item_action_added
[     3.2 MiB] [   7.62%]        g_object_thaw_notify
[     3.2 MiB] [   7.59%]        g_object_notify_by_pspec
[     3.2 MiB] [   7.55%]        g_object_freeze_notify
[   311 bytes] [   0.00%]      gtk_action_muxer_observer_action_added

After

    ALLOCATED      TOTAL    FUNCTION
[    45.2 KiB] [   0.11%]    gtk_action_muxer_action_added
[    19.6 KiB] [   0.05%]      g_object_notify_by_pspec
[    16.1 KiB] [   0.04%]      gtk_action_muxer_observer_action_added
[     9.0 KiB] [   0.02%]      gtk_menu_tracker_item_action_added
[   560 bytes] [   0.00%]      gtk_action_helper_action_added

I presume the additional allocations in After for other rows is simply because it was so much faster I was able to show the context menu more times before freezing. There is still more work to be done elsewhere on avoiding the quadratic nature (or worse) of whatever is happening though.

Edited by Christian Hergert

Merge request reports