<div dir="ltr"><div><br></div>Hi<br><div class="gmail_extra"><br><div class="gmail_quote">On 20 April 2016 at 18:27, James Cameron <span dir="ltr"><<a href="mailto:quozl@laptop.org" target="_blank">quozl@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, Apr 20, 2016 at 05:22:21PM -0400, Dave Crossland wrote:<br>
<span class="">><br>
> On 20 April 2016 at 16:46, James Cameron <[1]<a href="mailto:quozl@laptop.org">quozl@laptop.org</a>> wrote:<br>
><br>
>     the performance ratio between our low-cost<br>
>     low-power hardware and the competition was already evident on Fedora<br>
>     Linux; it didn't need Windows to expose it<br>
><br>
> Sorry if this is an obvious question, but, can anything done to make<br>
> Sugar feel faster on XO-1s today? <br>
<br>
</span>Yes, and I've been doing some of that in the past few months. </blockquote><div><br></div><div>AWESOME</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> With 13.2.7 you have my latest work, which added swap and removed several<br>
animations.<br></blockquote><div><br></div><div>Great :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Adding swap has mostly removed memory pressure.  </blockquote><div><br></div><div>Is it possible to configure the swap to run on the SD card, which, if failing due to thrashing, can easily be replaced?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Under memory<br>
pressure, activity startup is roughly doubled, </blockquote><div><br></div><div>WOW</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">as the CPU spends time thrashing in the memory management.  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Disadvantage is higher power cost<br>
and possibly decreased Flash endurance, although the endurance of a<br>
set of heavily used XO-1 has shown no sign of the deterioration<br>
expected by now.<br></blockquote><div><br></div><div>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.<br><br>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Removing animations has allowed CPU cycles to be better spent on<br>
responsiveness.  At one stage we had 50/50 competition between the<br>
activity launch animation and the starting activity. </blockquote><div><br></div><div>Woah :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> Instrumenting<br>
the frame and transition box animations showed there was enough time<br>
for only one or two intermediate animation states before the final<br>
state; which turned out to the cost of handling the function key<br>
release event.  Some of these changes are not in Sugar master yet, but<br>
in an OLPC branch; one such was proposed, but immediately closed with<br>
appeal to process;<br>
<br>
        <a href="https://github.com/sugarlabs/sugar/pull/619" rel="noreferrer" target="_blank">https://github.com/sugarlabs/sugar/pull/619</a></blockquote><div><br></div><div>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? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">As for what to do next; ideas are welcome, but here's a few;<br>
<br>
- profiling, of startup, of interactive response, (i've used xdotool<br>
  for interactive response tests),<br></blockquote><div><br></div><div>AWESOME! Could you make a screencast showing how to set this up? </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- upgrade Gtk3, and GObject, to fix the memory leaks,<br></blockquote><div><br></div><div>I like it!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- record metrics of response, deidentify, aggregate, and report.<br></blockquote><div><br></div><div>I think this kind of data driven development is crucially important :) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Although at this stage the interest in XO-1 should have degraded as<br>
the units have degraded, and any return on investment is doubtful.<br></blockquote><div><br></div><div>I'm not sure; even if the XO-1 units themselves are gone, the cheapest computers will always be puny, either (non-)refurbished clunkers passed down to kids, or $5 computers like the Raspbery Pi Zero. </div><div><br></div><div>By optimizing for XO-1, we optimize for spending power of small children. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Plenty of people left who whinge about XO-1, but ask them to test a<br>
patch or release and no response.<br></blockquote><div><br></div><div>Kindly, this is because you assume too much technical skills/experience on their part, and I suspect that there is a "tact filter mismatch" per <a href="http://www.mit.edu/~jcb/tact.html">www.mit.edu/~jcb/tact.html</a> :) </div><div><br></div><div>This was/is also a brake on the speed of development of the fontforge community, which is written in C and has its own X toolkit; the community of C developers were generally unwilling to 'baby step' enthusiastic but inexperienced community peers in how to apply and test patches. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
So it's more about people wanting their rainbow pooing unicorns.<br>
Unrealistic expectations, polarised framing, denial, and consequent<br>
unwillingness to be involved.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">I am again reminded of <a href="https://youtu.be/N9c7_8Gp7gI?t=9m1s">https://youtu.be/N9c7_8Gp7gI?t=9m1s</a> 9m1s to 10m23s as an amusing anecdote about how to work productively with people who are setting out to work against you :)</div><div class="gmail_extra"><br></div>-- <br><div class="gmail_signature">Cheers<br>Dave</div>
</div></div>