[Sugar-devel] Vision
Jerry Vonau
me at jvonau.ca
Wed Apr 20 19:29:21 EDT 2016
> On April 20, 2016 at 5:54 PM Dave Crossland <dave at lab6.com> wrote:
>
>
> Hi
>
> On 20 April 2016 at 18:27, James Cameron <quozl at laptop.org> wrote:
>
> > On Wed, Apr 20, 2016 at 05:22:21PM -0400, Dave Crossland wrote:
> > >
> > > On 20 April 2016 at 16:46, James Cameron <[1]quozl at laptop.org> wrote:
> > >
> > > the performance ratio between our low-cost
> > > low-power hardware and the competition was already evident on
> > > Fedora
> > > Linux; it didn't need Windows to expose it
> > >
> > > Sorry if this is an obvious question, but, can anything done to make
> > > Sugar feel faster on XO-1s today?
> >
> > Yes, and I've been doing some of that in the past few months.
>
>
> AWESOME
>
>
> > With 13.2.7 you have my latest work, which added swap and removed
> > several
> > animations.
> >
>
> Great :)
>
>
> > Adding swap has mostly removed memory pressure.
>
>
> Is it possible to configure the swap to run on the SD card, which, if
> failing due to thrashing, can easily be replaced?
>
>
> > Under memory
> > pressure, activity startup is roughly doubled,
>
>
> WOW
>
>
> > as the CPU spends time thrashing in the memory management.
>
> Disadvantage is higher power cost
> > and possibly decreased Flash endurance, although the endurance of a
> > set of heavily used XO-1 has shown no sign of the deterioration
> > expected by now.
> >
>
> Yes, it is somewhat astonishing to me that any XO-1 are still working at
> all :) I would have thought they'd all have cracked screens and ripped
> keyboards by now.
>
> Maybe this was brought up on the XO-1 thread I started, but I didn't
> remember if so; does anyone has any suggestions about how many XO-1s are
> still in use?
>
>
> > Removing animations has allowed CPU cycles to be better spent on
> > responsiveness. At one stage we had 50/50 competition between the
> > activity launch animation and the starting activity.
>
>
> Woah :)
>
>
> > Instrumenting
> > the frame and transition box animations showed there was enough time
> > for only one or two intermediate animation states before the final
> > state; which turned out to the cost of handling the function key
> > release event. Some of these changes are not in Sugar master yet, but
> > in an OLPC branch; one such was proposed, but immediately closed with
> > appeal to process;
> >
> > https://github.com/sugarlabs/sugar/pull/619
>
>
> I sympathise with Sam's request to discuss further; eg, perhaps there is
> a
> compromise by wrapping the decision to animate in an if/else block that
> checks some cpuinfo in /proc, or if the number of running activities can
> be
> obtained very cheaply through a len() call or something?
>
>
> > As for what to do next; ideas are welcome, but here's a few;
> >
> > - profiling, of startup, of interactive response, (i've used xdotool
> > for interactive response tests),
> >
>
> AWESOME! Could you make a screencast showing how to set this up?
>
>
> > - upgrade Gtk3, and GObject, to fix the memory leaks,
> >
>
> I like it!
>
>
You are referring to updating the underling OS from F18/20 to
current(F22/F23/F24) to match the current SoaS offering? For the
XO-1/XO-1.5 that is a pile easier to do giving you can run OSBuilder on
pretty much any X86 host. There are warning about running OSBuilder under a
different host OS from the target but I've been successful in building
XO-1.5 images and having them boot. At least the door is open for further
digging, debugging and refinement.
Jerry
More information about the Sugar-devel
mailing list