Re: Quick tabbing profiling (was Re: Report on `activities switching' profiling)
2008/7/18 Benjamin Berg [EMAIL PROTECTED]: Hello, On Fri, 2008-07-18 at 12:51 -0400, Eben Eliason wrote: 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. Outch. It is right that the activities are saving their state all the time. I forgot about the messages send to the activities. Which means that the activities are active even though the window is not raised. We may need a more complicated scheme to keep track of the activities during tabbing. Much more complicated? Perhaps we should have a TabbingContext class to keep track of these things, so we don't add too much complexity to classes like Shell and ShellModel? How bad is this issue from the user point of view? In my opinion, if we can land one important feature like this on one milestone, and improve its performance on the next one, that's quite probably the best we can do with the available resources. If we optimize too late in the release cycle, we may introduce too many bugs and greatly affect the stability of the whole product. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Quick tabbing profiling (was Re: Report on `activities switching' profiling)
On Sat, 2008-07-19 at 12:18 +0200, Tomeu Vizoso wrote: 2008/7/18 Benjamin Berg [EMAIL PROTECTED]: We may need a more complicated scheme to keep track of the activities during tabbing. Much more complicated? Perhaps we should have a TabbingContext class to keep track of these things, so we don't add too much complexity to classes like Shell and ShellModel? The current code assumes that one can just switch the active Activity right away, but only raise the window on a delay. This does not work. I already had some code in my first series of patches that would keep track of a tabbing-activity separately from the active-activity (in the HomeModel). This, together with some other changes, will be needed to fix the issue. How bad is this issue from the user point of view? Tabbing is still better than it was before my patches landed. But I do expect that fixing this will be nice improvement in in tabbing experience. In my opinion, if we can land one important feature like this on one milestone, and improve its performance on the next one, that's quite probably the best we can do with the available resources. If we optimize too late in the release cycle, we may introduce too many bugs and greatly affect the stability of the whole product. Of course, destabilising sugar should not be an option. I am planning to look into this at the end of next week. So I hope to have a patch by Friday or Saturday. Benjamin signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Quick tabbing profiling (was Re: Report on `activities switching' profiling)
Hello, On Fri, 2008-07-18 at 12:51 -0400, Eben Eliason wrote: 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. Outch. It is right that the activities are saving their state all the time. I forgot about the messages send to the activities. Which means that the activities are active even though the window is not raised. We may need a more complicated scheme to keep track of the activities during tabbing. Benjamin signature.asc Description: This is a digitally signed message part ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Report on `activities switching' profiling
On Wed, 2008-07-16 at 11:17 -0400, Eben Eliason wrote: On Wed, Jul 16, 2008 at 11:04 AM, riccardo [EMAIL PROTECTED] wrote: (so that it never ends up in the journal) every 1100. The 1100ms value was chosen after some testing as the minimum value (or very near to it) at which both activities are able to completely redraw their windows on switching without artifacts. If you could, it would also be useful to test out the quick tab behavior. While it's true that after a short delay (I forget the exact number of ms) the activities redraw their windows, the behavior is supposed to prevent this redraw as long as the tabbing events happen quickly enough, so that the redraw doesn't add latency when attempting to bypass several activities in a row. I'm not sure if this is actually working properly on the XOs. Sure, I let you know when I have some results. I guess some time can be gained by not doing the conversion Drawable - GdkPixbuf (sugar._sugarext.Preview.get_pixbuf) and perform the scaling and conversion directly on the first buffer. But IMHO the real problem is: ! Activities save their state and take previews continuously regardless of whether their state changed or not Yeah, this would indeed be a problem. This ticket -- http://dev.laptop.org/ticket/4365 -- deals with it to some extent, and a patch is present there, but it's been ignored for some time now. - Eben riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Report on `activities switching' profiling
Hi, Problem: switching between activities is noticeably too slow. Test-case: the test consist of starting Chat and Write and switching between them for a sensible amount of time. All tests were run on a xo. Switching was automated by patching sugar-shell to call shell.activate_next_activity() or shell.activate_previous_activity() (so that it never ends up in the journal) every 1100. The 1100ms value was chosen after some testing as the minimum value (or very near to it) at which both activities are able to completely redraw their windows on switching without artifacts. The following tab. and fig. show cpu time usage of the five processes taking more cpu time while running the test (the first two processes are chat and write). (tot% us+sy) - (partial% us+sy) : cmdline 28.9 - 28.9 : python /usr/sbin/rainbow-daemon --daemon 54.7 - 25.8 : python /usr/sbin/rainbow-daemon --daemon 66.5 - 11.7 : /usr/bin/X :0 -fp built-ins -wr -auth /home/olpc/.serverauth.1861 76.9 - 10.3 : python /usr/bin/datastore-service 85.3 - 8.4 : python /usr/bin/sugar-shell http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/stats.picker.p84.svg (http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/stats.picker) They were obtained by running: $ picker -t30 -f10 $ grapher -c5 ! 55% of cpu time goes to the activities, to do what? The two following files are cProfile statistics formatted to be viewed with KCacheGrind for the chat and write activity: http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/cProfile-chat http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/cProfile-write Ordering by function's self-time we have for chat: part% func name 17.3 : gtk.gdk.Pixbuf.scale_simple 13.6 : sugar._sugarext.Preview.get_pixbuf 10.4 : gtk.gdk.Pixbuf.save 6. : sugar._sugarext.Preview.take_screenshot -- 47.3% Values are almost the same for write. I guess some time can be gained by not doing the conversion Drawable - GdkPixbuf (sugar._sugarext.Preview.get_pixbuf) and perform the scaling and conversion directly on the first buffer. But IMHO the real problem is: ! Activities save their state and take previews continuously regardless of whether their state changed or not Next, cProfile statistics for the shell: http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/cProfile-shell Ordering by function self-time we have: part% func name 14.5 : set_message_with_reply_and_block of dbus 6.1 : cycle 6 2.58 : __init__ of sugar/graphics/palette.py cycle 6 1.65 : cairo.context.paint I don't understand what cycle 6 refers to (it appears also in the third entry); maybe Tomeu knows ? ;) Btw the shell is taking only the 8.4% of the total cpu time. There also cProfile statistics for the DS and the Journal but they are not very interesting this time: http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/cProfile-datastore http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/cProfile-journal The last tool we used is sysprof: http://dev.laptop.org/~rlucchese/ActivitiesSwitching/chat-write/stats.sysprof What it shows is somehow more difficult to comment on; I think is much more clear to just look at sysprof. Much time is spent in __PangoFontset_class_init-__do_global_ctors_aux; is this libpango or the python-pango bindings being 'reloaded' at every switch ? Next, `notable' thing is a memcpy in the xorg libfb module; all the screenshots ? libcairo doesn't seem to show up particularly. Did I miss something interesting in these tests ? Thanks, riccardo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Report on `activities switching' profiling
On Wed, Jul 16, 2008 at 11:04 AM, riccardo [EMAIL PROTECTED] wrote: (so that it never ends up in the journal) every 1100. The 1100ms value was chosen after some testing as the minimum value (or very near to it) at which both activities are able to completely redraw their windows on switching without artifacts. If you could, it would also be useful to test out the quick tab behavior. While it's true that after a short delay (I forget the exact number of ms) the activities redraw their windows, the behavior is supposed to prevent this redraw as long as the tabbing events happen quickly enough, so that the redraw doesn't add latency when attempting to bypass several activities in a row. I'm not sure if this is actually working properly on the XOs. I guess some time can be gained by not doing the conversion Drawable - GdkPixbuf (sugar._sugarext.Preview.get_pixbuf) and perform the scaling and conversion directly on the first buffer. But IMHO the real problem is: ! Activities save their state and take previews continuously regardless of whether their state changed or not Yeah, this would indeed be a problem. This ticket -- http://dev.laptop.org/ticket/4365 -- deals with it to some extent, and a patch is present there, but it's been ignored for some time now. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
