<div dir="ltr">On 19 November 2013 07:08, Sebastian Silva <span dir="ltr"><<a href="mailto:sebastian@fuentelibre.org" target="_blank">sebastian@fuentelibre.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">- What is slow exactly?<div class="im"><blockquote type="cite">
</blockquote></div>
Initial startup, switch between activities, activity startup. Also
probably redraw after widget damage e.g. the Frame appears. Then
again it's hard to pinpoint exactly, just out of memory now.<div class="im"><br>
<blockquote type="cite">
<div>- Why do you believe it's an issue with low level libraries
(and which libraries)?</div>
</blockquote></div>
I like to dogfood. I do all my work on a low end atom netbook. I
have observed in my own use how applications ported to GTK3 have
degraded performance (e.g. Evince, Gnumeric). I have come to expect
this, really as I experienced the same thing when moving as a user
from GTK1 to GTK2.<br></div></blockquote><div><br></div><div>Thanks these are the kind of subjective impressions I was hoping to get my questions. I have never seen Sugar on XO 1 myself :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote type="cite">
<div>- Did you profile?</div>
</blockquote>
Nope, but our images are still in beta and I'd be willing to profile
and share the results by default. If it will help then we can have a
metric.</div></blockquote><div><br><br></div><div>I think there are a couple of things that would be worth profiling as a first pass<br><br></div><div>* Free memory at boot.<br></div><div>* Clear kernel cache. Start HelloWord, measuring startup time. Start HelloWorld again measuring startup time.<br>
<br></div><div>Ideally we would test these on old OS + gtk2, old OS + gtk3 (assuming the images you are working with support gtk3 toolkit at all), new OS.<br><br></div><div>Note that I'm not saying you should do that work (though it would be great of course :P). I was asking if you had done an profiling and you could share it... <br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>Please don't assume people knows what they are talking about
when they speak about performance, unless they back up their
claims with profiling data, especially if they are
just saying things are "lighter" and base a toolkit switch on
that!</div>
</blockquote>
<br></div>
I'm sure that they at least carefully measured the memory usage. On
XO1 this is critical with only 256mb ram. Also the OS by default has
no swap.</div></blockquote><div><br></div><div>I will not be sure until I see the numbers and metodology, measuring memory usage on linux is *hard*.<br><br>The library size might have increased, but I doubt that's going to make much of a difference even on 256mb because it will be shared by all the processes.<br>
<br></div><div>I'm not saying there has not been regression. But I think there are a good chances they might be fixable with a reasonable amount of resources. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>I know fairly well what changed between gtk2 and gtk3 and I
have a very very hard time believing it introduced unfixable
regressions. By design things should have improved, as far as I
know. The problem is probably more that, as usual, the
performance of the system developers works with has improved,
thus with changes comes regressions that are not noticed. And the only way to counter that is to profile and fix the
real issues...</div>
</blockquote></div>
Understood. However it's a little out of my league, I admit. I tend
to focus on serving low hanging fruit in a user friendly plate. This
is why distributions interest me so much.</div></blockquote><div><br></div><div>Of course, not many people like performance work.<br><br>My point is that if we target low end hardware and we use something which normally used on much faster machines, then we can't hope it performs well unless we at very least spend some time profiling and reporting issues. Someone has to do that work.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>I'm personally going to focus on newer hardware, but then
isn't XO 1 most of our user base currently? It seems we need to
balance research and continued support here... Also note that
the new hardware isn't going to be blazing fast either, the
issue we find there are most likely very similar to the ones on
the XO 1, just to a lesser scale. If we improve XO 1, other
hardware will most likely improve too.</div>
</blockquote></div>
Yes, only in newer hardware the impression that the Sugar user
experience is not very good is not really related to performance, or
at least, not primarily.</div></blockquote><div><br></div><div>On my laptop I certainly can't notice any performance issue. But, for example, on the XO 1.75 I think performance is infuriating. If you don't see that anymore you must have spent too much time dogfooding :P<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<blockquote type="cite">
<div>I think we need to get much better collectively at working on
performance, it's a key aspect of the kind of hardware we are
targeting and my feeling is that a lot of people don't like
Sugar mostly because it's so slow...</div>
</blockquote></div>
A platform is about the applications available to it. Sugar in my
opinion has issues here as well. I tend to concur with Flavio that
some aesthetics rework wouldn't hurt either. For what it's worth I
always found interesting what the advertising firm that worked on
Sugar published in their website:
<a href="http://new.pentagram.com/2006/12/new-work-one-laptop-per-child/" target="_blank">http://new.pentagram.com/2006/12/new-work-one-laptop-per-child/</a><br>
<br>
On the topic of aesthetics, it's interesting to see what even
happens with adding a compositor (in metacity's gconf key) and
changing some colors in style.py<br>
I recently noticed that in ancient versions (pre 0.82) the Journal
items were separated with a thin line. This helped readability and
gave the sense that each line was an object.<br>
<br>
Maybe I just went off topic (again) but now that we are sharing...<br></div></blockquote><div><br></div><div>There would be a lot to discuss about UX but honestly until we figure out how to work together I don't feel much like going on that topic. We are unlikely to find common ground on something that complex if we can't even sync on basic profiling (I'm referring to the rest of the thread, not to this email).<br>
<br>And even if we had productive discussion we would not have resources to implement the changes. IMO there are some resources but they are too dispersed because we are unable to work together.<br></div></div></div></div>