<div dir="ltr">Can someone make sense of this for me? Ben, do you see anything we can optimize here? I've noticed while quick-tabbing on my XO that the gray selection box doesn't usually update as I switch, so I can't tell where I am. If I pause long enough to see the selection move, I also get the redraw of the whole activity, slowing me down and defeating the purpose.<div>
<br></div><div>- Eben</div><div><br><br><div class="gmail_quote">On Fri, Jul 18, 2008 at 6:08 AM, riccardo <<a href="mailto:riccardo.lucchese@gmail.com">riccardo.lucchese@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Thu, 2008-07-17 at 10:31 +0200, riccardo wrote:<br>
> On Wed, 2008-07-16 at 11:17 -0400, Eben Eliason wrote:<br>
> ><br>
> ><br>
> > On Wed, Jul 16, 2008 at 11:04 AM, riccardo<br>
> > <<a href="mailto:riccardo.lucchese@gmail.com">riccardo.lucchese@gmail.com</a>> wrote:<br>
> > (so that it never ends up in the journal) every 1100. The<br>
> > 1100ms value<br>
> > was chosen after some testing as the minimum value (or very<br>
> > near to it)<br>
> > at which both activities are able to completely redraw their<br>
> > windows on<br>
> > switching without artifacts.<br>
> ><br>
> ><br>
> > If you could, it would also be useful to test out the "quick tab"<br>
> > behavior. While it's true that after a short delay (I forget the<br>
> > exact number of ms) the activities redraw their windows, the behavior<br>
> > is supposed to prevent this redraw as long as the tabbing events<br>
> > happen quickly enough, so that the redraw doesn't add latency when<br>
> > attempting to bypass several activities in a row. I'm not sure if<br>
> > this is actually working properly on the XOs.<br>
><br>
> Sure, I let you know when I have some results.<br>
><br>
<br>
Test-case: the test consist of starting few activities and<br>
`quick-tabbing' between them for a sensible amount of time. Switching<br>
was automated by patching sugar-shell to call<br>
tabbinghandler.handle_next_activity() every 100ms; this value should<br>
trigger the `quick-tabbing' logic. All tests were run on a xo<br>
<br>
The following tab. and fig. show cpu time usage of the 8 processes<br>
taking more cpu time while running the test (pid 2233 and 2254 are two<br>
activities).<br>
<br>
(tot% us+sy) - (partial% us+sy) : cmdline<br>
- 39.8 : python /usr/bin/sugar-shell<br>
75.0 - 35.1 : python /usr/bin/datastore-service<br>
82.7 - 7.6 : picker -t30<br>
86.5 - 3.8 : /bin/dbus-daemon --fork --print-pid 5 ...<br>
88.9 - 2.3 : python /usr/bin/sugar-presence-service<br>
90.8 - 1.8 : python /usr/sbin/rainbow-daemon --daemon (2233)<br>
92.7 - 1.8 : python /usr/bin/sugar-activity journalactivity.Jou...<br>
94.3 - 1.6 : python /usr/sbin/rainbow-daemon --daemon (2254)<br>
<br>
<a href="http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/picker.stats.svg" target="_blank">http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/picker.stats.svg</a><br>
(<a href="http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/picker.stats" target="_blank">http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/picker.stats</a>)<br>
<br>
They were obtained by running:<br>
$ picker -t30 -f10<br>
$ grapher -c8<br>
<br>
! 75% of cpu-time goes to the shell and the datastore.<br>
<br>
next_activity() and previous_activity() in tabbinghandler.py call<br>
tabbing_set_activity(self, activity) in homemodel.py that in turn<br>
calls SetActive(False, ...) on the current activity and<br>
SetActive(True, ...) on the next activity.<br>
<br>
<br>
cProfile statistics (KCacheGrind format) for the shell and the<br>
datastore:<br>
<a href="http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/cProfile-shell" target="_blank">http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/cProfile-shell</a><br>
<a href="http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/cProfile-datastore" target="_blank">http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/cProfile-datastore</a><br>
<br>
Ordering by function's self-time we have for sugar-shell:<br>
part% func name<br>
26.8 : gtk.main()<br>
11.9 : send_message_with_reply_and_block of dbus<br>
8.2 : call_async of dbus<br>
5.7 : __init__ in sugar/graphics/palette.py 8.2 <cycle 5><br>
5.3 : __init__ in sugar/graphics/icon.py<br>
3.3 : gtk.Widget.show() <cycle 5><br>
1.6 : gobject.GObject.connect()<br>
----------------------------------------------<br>
62%<br>
<br>
Where <cycle 5> means there is recursion between those functions.<br>
<br>
Ordering by function's self-time we have for the datastore:<br>
part% func name<br>
41.9 : gobject.MainLoop.run<br>
5.8 : flush in secore/indexerconnection.py<br>
5.7 : posix.fork<br>
3.9 : send_message of dbus<br>
3.1 : replace in secore/indexerconnection.py<br>
2.8 : cPickle.dumps<br>
1.8 : perform in secore/fieldactions.py<br>
1.5 : properties in datastore/model.py<br>
----------------------------------------------<br>
67%<br>
<br>
<br>
I think sysprof statistics aren't extremely interesting in this case:<br>
<a href="http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/sysprof.data" target="_blank">http://dev.laptop.org/~rlucchese/ActivitiesSwitching/quick-tabbing/sysprof.data</a><br>
<br>
<br>
<br>
thanks,<br>
<font color="#888888">riccardo<br>
<br>
</font></blockquote></div><br></div></div>