Archive for WSOP06-Gnome


Comments (10)


I tested the new behaviour of switching not only for mail, and this is the result of 500 set of 4 switches (mail -> contacts -> calendar -> tasks -> memos). Results for almost all the components are satisfactory – constant times rounding 0,1 seconds. But we can observe a soft tendency of mail to grow, which wasn’t perceptible with less number of iterations (see the post below).

Comments (2)


Patch and changelog (for libbonoboui).

After exploring many debugging outputs and gdb stack traces I realized that an accelerator was changed whenever the node of the xml tree that represented a specific menu widget was marked as “dirty”. In the process of merging the several xml trees a node could be set dirty depending on the command that represent. Some commands need to be synchronized; this sync is transferred to the node, for example in impl_bonobo_ui_sync_menu_state. But the problem that this function had was the chaotic addition of accelerators which made an expensive growth of structures, memory leaks included.

The patch respects the fact that we can have a widget with multiple accelerators and that the same accelerator can be added many times in the same accelerator group. The code only avoid the accelerator addition if it has been added previously to the same widget (which is the common case).

A chart with the difference of the old and new behaviour of component mail switching (200 switches).

200 switches

After each switch, evo sleep, for avoiding the linux scheduler interference. Other charts didn’t take into account that, but it doesn’t matter, because the effects and conclusions were the same. For example, the following chart represents a massive 200-switching. The old version never stops growing and the new one become stable in a specific threshold, determined by the end of an epoch in the Linux scheduler (probably evo should be at the end of the runqueue, but starvation doesn’t happen).

200 switches

* Edited * I’ve changed the patch because it had a little problem of memory leaking. Thanks Benoît Dejean for your remark!

Comments (15)

More accelerators

The increase of time of g_memmove() at quick_accel_add() is due to some accelerators that are added and never removed. For each iteration we have 42 accelerators more which will remain in memory till evo is closed. Specifically, they are only 6 generic accelerators (*Control**Shift*s, F1, *Control**Shift*w, F9, *Control*w, *Control*q) but that are added 7 times. The 7-times-addition happens for all the others too, but every time they are added with a different closure.

I uploaded here the log where we can see the mentioned problem. There are 100 switches, every one starts with the word “ITERACION #”, then the last accelerators are removed (I print the pointer to the closure and the current number of accelerators) and are added the new needed (I print some data like id of widget, accelerator and closure, number of accelerators, position in the vector and time of g_memmove).

Comments (2)

accelerators never die

The last findings have been very interesting.

The following chart shows the behaviour of gtk_widget_add_accelerator(), method invoked by bonobo_ui_sync_menu_state. Here is where the time increases. Each point represents the sum of the times of all the add_accelerator in a switch, so there are 100 switches:

Analysing the code we reach finally a g_memmove at quick_accel_add(), with the following behaviour:

Moreover, if we print the number of accelerators at an accelerator group the value always grow, like if some of the accelerators hasn’t been removed at the deactivation of the component in a switch.

Leave a Comment


em_folder_view_activate() is, according to sysprof, the function which consumes an important amount of time in a switching. This function calls a lot of methods. I measure the time of its methods and keep the more significant for elaborate the following charts:

– for 100 switches: 100it_emfv

– for 400 switches: 400it_emfv

The first remarks:

– The the behaviour of time growth seen at previous charts continue; I mean the drastic hop that suffer the switching between iteration 20 to 50 (+/-).

– I haven’t found a specific method responsible of the increase of time, almost all of them increase their time, although bonobo_util_set_ui() is always the function which takes more time.

Comments (1)

Come back

Ok, there’s a lot of days I don’t post. I’ve been at Galicia, with my grandparents and I had few opportunities to connect to the net.
In these days I had profiled Evo in many stages of the component switching and I had take more timing tests of situations I considered relevant to understand the profiling.
I put timers in the functions component_view_activate and component_view_deactivate, which are called in every switch. For mail (the component with the worst behaviour) the time of activation is, firstly, over the time of deactivation and both times increase in every iteration. But after many iterations the time of deactivation increases over the time of activation.
For example, the first switch takes:
deactivate: 0,030000; activate: 0,340000
And after 300 iterations we get:
deactivate: 1,360000; activate: 1,120000
Due to this increasing of the time of mail deactivation I got in this chart the increase of component contacts, which should deactivate mail.

Besides, sysprof says that the responsible of the bottleneck in components activation/deactivation is the processing of xml. I’m right now analysing that set of functions. Perhaps the best way for optimise this part of the code is specialisation by eliminating communication in xml. Is it an sacrilege?

Comments (1)

Older Posts »