Report

Comments (9)

Remark

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

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:

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

gmem
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()

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)

gnuLinEx and Iberia

Yesterday I flied from Santiago to Tenerife with the Spanish airline Iberia and I found a great surprise on my seat: a CD of Linex, the Linux distribution of Junta de Extremadura.
cd

Moreover, the air assistant promoted the distro when she had to talk to the passengers… “gnuLinEx is free software, total virus absence…”.

And everywhere we could find advertising of LinEx: on the cloth where we lean the head, the refreshing towel and other stuff (exemple:)

things

Congratulations to Junta de Extremadura! I’ve loved this initiative, Linux closer than ever to the people don’t know about it.

(and congratulations to my blog provider for deleting almost the whole post and making me re-edit it ¬¬’) (twice!)

Comments (3)

Older Posts »
Follow

Get every new post delivered to your Inbox.