[Sugar-devel] Research: 0.84 Launcher Cost
Earlier in the context of SL#2080 patch review, I had said "the launcher is stealing CPU cycles from the startup of the activity, the task run queue shows this during a launch. I wonder if activities might start up faster if there was no launcher, just a busy cursor." Looks like activities would start faster; between one and four seconds, mostly depending on the activity, and slightly depending on the icon complexity. Details below. -- Research: will activities start faster if there is no launcher? Method: using an XO-1, freshly installed with Sugar 0.84.22, as part of OLPC OS 10.1.2 build os852, test the startup time of three activities (Memorize, Moon and Chat), remove the launcher, retest, subtract. The launcher is implemented by source file launcher.py in /usr/lib/python2.6/site-packages/jarabe/view/ ... the modification made is attached as a patch. The times were captured with a stopwatch. The timing began when "Start" was selected from the list view, and ended once the activity had completed display of the UI. Result: a. unmodified launcher.py Memorize-34 9.43s, 9.56s, 9.51s Moon-11 11.58s, 11.60s, 11.65s Chat-65 6.65s, 6.54s, 6.59s b. modified launcher.py (black background, no animation), Memorize-34 7.60s, 7.63s, 7.60s Moon-11 7.78s, 7.78s, 7.95s Chat-65 5.04s, 4.93s, 4.88s c. calculated cost of launcher Memorize-34 1.89s Moon-11 3.73s Chat-65 1.64s Diagnosis: removing the launcher animation saved between one and four seconds of startup time. The saving was greatest for the Moon activity. -- Research: determine if the SVG icon for the Moon activity contributes to the delay. Method: swap the icons, restart Sugar, retest only Chat activity with Moon icon. Result: a. unmodified launcher.py Chat-65 7.83s, 7.59s, 7.62s b. modified launcher.py (black background, no animation), Chat-65 4.99s, 4.87s, 4.90s c. calculated cost of launcher Chat-65 2.75s (greater than previous) d. calculated cost of moon icon over chat icon Chat-65 1.09s Diagnosis: the degree of saving has a little to do with the SVG icon complexity. The degree of saving has much to do with the mix of operations performed by the activity during startup. -- So, between 23 and 92 wasted days of looking at the launcher across two million laptops. Good time to think and plan, kids. -- James Cameron http://quozl.linux.org.au/ --- launcher.py.orig 2010-10-28 02:56:43.0 + +++ launcher.py 2010-10-28 02:58:18.0 + @@ -35,13 +35,13 @@ self.props.type_hint = gtk.gdk.WINDOW_TYPE_HINT_NORMAL canvas = hippo.Canvas() -canvas.modify_bg(gtk.STATE_NORMAL, style.COLOR_WHITE.get_gdk_color()) +canvas.modify_bg(gtk.STATE_NORMAL, style.COLOR_BLACK.get_gdk_color()) self.add(canvas) canvas.show() self._activity_id = activity_id -self._box = LaunchBox(activity_id, icon_path, icon_color) -canvas.set_root(self._box) +#self._box = LaunchBox(activity_id, icon_path, icon_color) +#canvas.set_root(self._box) self.connect('realize', self.__realize_cb) @@ -52,7 +52,7 @@ def show(self): self.present() -self._box.zoom_in() +#self._box.zoom_in() def _update_size(self): self.resize(gtk.gdk.screen_width(), gtk.gdk.screen_height()) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Research: 0.84 Launcher Cost
Hello James, I was going through the discussion over the bug #2080 handled currently by Anurag. I too was thinking of replacing the animation algo, which currently is sine function. I was having some questions in mind after looking at your research. "When launcher is disabled, the time saving is more, as compared to SVG complexity." If we are not for removing animation, then why not use a simple integer based algorithm instead of a floating based sine algorithm. In terms of graphics, integer based algorithms (Bresenham, Mid-point, etc) work faster than floating point based. If we can use a 'Busy-Cursor' then its fine. But if we still want to continue with the animation, why not change the algorithm for the animation that is done? Regards, Dipankar On Thu, Oct 28, 2010 at 9:04 AM, James Cameron wrote: > Earlier in the context of SL#2080 patch review, I had said "the > launcher is stealing CPU cycles from the startup of the activity, the > task run queue shows this during a launch. I wonder if activities > might start up faster if there was no launcher, just a busy cursor." > > Looks like activities would start faster; between one and four seconds, > mostly depending on the activity, and slightly depending on the icon > complexity. > > Details below. > > -- > > Research: will activities start faster if there is no launcher? > > Method: using an XO-1, freshly installed with Sugar 0.84.22, as part > of OLPC OS 10.1.2 build os852, test the startup time of three > activities (Memorize, Moon and Chat), remove the launcher, retest, > subtract. > > The launcher is implemented by source file launcher.py in > /usr/lib/python2.6/site-packages/jarabe/view/ ... the modification > made is attached as a patch. > > The times were captured with a stopwatch. The timing began when "Start" > was selected from the list view, and ended once the activity had > completed display of the UI. > > Result: > > a. unmodified launcher.py > > Memorize-34 9.43s, 9.56s, 9.51s > Moon-11 11.58s, 11.60s, 11.65s > Chat-65 6.65s, 6.54s, 6.59s > > b. modified launcher.py (black background, no animation), > > Memorize-34 7.60s, 7.63s, 7.60s > Moon-11 7.78s, 7.78s, 7.95s > Chat-65 5.04s, 4.93s, 4.88s > > c. calculated cost of launcher > > Memorize-34 1.89s > Moon-11 3.73s > Chat-65 1.64s > > Diagnosis: removing the launcher animation saved between one and four > seconds of startup time. The saving was greatest for the Moon activity. > > -- > > Research: determine if the SVG icon for the Moon activity contributes > to the delay. > > Method: swap the icons, restart Sugar, retest only Chat activity with > Moon icon. > > Result: > > a. unmodified launcher.py > > Chat-65 7.83s, 7.59s, 7.62s > > b. modified launcher.py (black background, no animation), > > Chat-65 4.99s, 4.87s, 4.90s > > c. calculated cost of launcher > > Chat-65 2.75s (greater than previous) > > d. calculated cost of moon icon over chat icon > > Chat-65 1.09s > > Diagnosis: the degree of saving has a little to do with the SVG icon > complexity. The degree of saving has much to do with the mix of > operations performed by the activity during startup. > > -- > > So, between 23 and 92 wasted days of looking at the launcher across > two million laptops. Good time to think and plan, kids. > > -- > James Cameron > http://quozl.linux.org.au/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Research: 0.84 Launcher Cost
G'day Dipanker, My research was not intended to propose a design change. I'm happy with how the launcher appears, and I think it adds considerable value to the learning experience of the child. I'm slightly not happy with delaying the startup of an activity, and I see that as a defect. I don't believe the use of floating point is costly. GTK+ uses floating point extensively. The time spent computing the sine function (in __pulse_cb) is minimal compared to the rendering time (render_cairo). A precalculated fix sine table could reduce the cost of the sine function, if it were a problem, which it is not. Reducing the amount of rendering may help, and that was what I proposed in the patch thread just now. But again, there's a drawback of caching. Activity startup time is more of a concern to me. You might wish to propose to the design team a configuration option that will suppress the launcher so as to improve startup time. I don't plan to propose that. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Research: 0.84 Launcher Cost
On 28 Oct 2010, at 04:34, James Cameron wrote: > Earlier in the context of SL#2080 patch review, I had said "the > launcher is stealing CPU cycles from the startup of the activity, the > task run queue shows this during a launch. I wonder if activities > might start up faster if there was no launcher, just a busy cursor." > > Looks like activities would start faster; between one and four seconds, > mostly depending on the activity, and slightly depending on the icon > complexity. > > Details below. > > -- > > Research: will activities start faster if there is no launcher? > > Method: using an XO-1, freshly installed with Sugar 0.84.22, as part > of OLPC OS 10.1.2 build os852, test the startup time of three > activities (Memorize, Moon and Chat), remove the launcher, retest, > subtract. > > The launcher is implemented by source file launcher.py in > /usr/lib/python2.6/site-packages/jarabe/view/ ... the modification > made is attached as a patch. > > The times were captured with a stopwatch. The timing began when "Start" > was selected from the list view, and ended once the activity had > completed display of the UI. > > Result: > > a. unmodified launcher.py > > Memorize-34 9.43s, 9.56s, 9.51s > Moon-11 11.58s, 11.60s, 11.65s > Chat-65 6.65s, 6.54s, 6.59s > > b. modified launcher.py (black background, no animation), > > Memorize-34 7.60s, 7.63s, 7.60s > Moon-11 7.78s, 7.78s, 7.95s > Chat-65 5.04s, 4.93s, 4.88s > > c. calculated cost of launcher > > Memorize-34 1.89s > Moon-11 3.73s > Chat-65 1.64s > > Diagnosis: removing the launcher animation saved between one and four > seconds of startup time. The saving was greatest for the Moon activity. Agreed, when Wade was working on this a year back or so, we came to the same estimate of about 4 sec for the launcher (should be in the mail list archives somewhere). I mentioned in a previous email that Wade managed to shave ~2 sec off this by pausing at the peek and trough of the pulse sine wave. However this did not land in time, so this is still 2sec up for grabs if some one wants to tweak and add pulse delays... You might even find Wade's patches for this ready to go if you go digging - I seem to remember the only reason it didn't land was a lack of time to test the change (was just Wade and me testing I think). --Gary > -- > > Research: determine if the SVG icon for the Moon activity contributes > to the delay. > > Method: swap the icons, restart Sugar, retest only Chat activity with > Moon icon. > > Result: > > a. unmodified launcher.py > > Chat-65 7.83s, 7.59s, 7.62s > > b. modified launcher.py (black background, no animation), > > Chat-65 4.99s, 4.87s, 4.90s > > c. calculated cost of launcher > > Chat-65 2.75s (greater than previous) > > d. calculated cost of moon icon over chat icon > > Chat-65 1.09s > > Diagnosis: the degree of saving has a little to do with the SVG icon > complexity. The degree of saving has much to do with the mix of > operations performed by the activity during startup. > > -- > > So, between 23 and 92 wasted days of looking at the launcher across > two million laptops. Good time to think and plan, kids. > > -- > James Cameron > http://quozl.linux.org.au/ > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Research: 0.84 Launcher Cost
On Fri, Oct 29, 2010 at 02:41:48AM +0100, Gary Martin wrote: > On 28 Oct 2010, at 04:34, James Cameron wrote: > > Diagnosis: removing the launcher animation saved between one and > > four seconds of startup time. The saving was greatest for the Moon > > activity. > > Agreed, when Wade was working on this a year back or so, we came to > the same estimate of about 4 sec for the launcher (should be in the > mail list archives somewhere). I mentioned in a previous email that > Wade managed to shave ~2 sec off this by pausing at the peek and > trough of the pulse sine wave. However this did not land in time, so > this is still 2sec up for grabs if some one wants to tweak and add > pulse delays... You might even find Wade's patches for this ready to > go if you go digging - I seem to remember the only reason it didn't > land was a lack of time to test the change (was just Wade and me > testing I think). Ah, right, it's all been tried before then. No worries. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel