<div class="gmail_quote">On Tue, Feb 3, 2009 at 10:46 PM, Benjamin M. Schwartz <span dir="ltr"><<a href="mailto:bmschwar@fas.harvard.edu" target="_blank">bmschwar@fas.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<div><br>
<a href="mailto:david@lang.hm" target="_blank">david@lang.hm</a> wrote:<br>
> the fact that KDE and GNOME (both desktops that are considered pigs on<br>
> normal machines) make a XO laptop seem snappy by comparison to Sugar (as<br>
> of December) means that there is a significant problem with Sugar.<br>
<br>
</div>I'm not happy to simply take this as "fact". It's either a measurement or<br>
an opinion.</blockquote><div><br>It's a fact. I have installed xfce in NAND together with Sugar and I'm running Opera with four tabs(one with the heavy gmail) and terminal - using 136MiB and no swap. Opera seems to leak memory though, it was only of <b>120MiB</b> when it had the four tabs oppened and not much usage, the same test scenario as with browse. Browse was a lot better at maintaining a more constant footprint, though.<br>
Adding a PDF in Acrobat(evince doesn't install easily) added this to 157MiB and 40MiB of swap.<br><br>Sugar, terminal open 111MiB, add a browse and it climbs to <b>165MiB</b> with gmail open. Add a PDF and it gets to 181MiB and 6 of swap memory in use.<br>
<br>My biggest problem with python has always been memory usage, not speed. In the XO, memory usage is far more important than speed(although graphics rendering is quite slow), IMHO, especially with XOs being deployed without swap.<br>
I have run the Pardus distro in a few computers, it was quite nice but had two or three apps(like network applet) written in python. Memory usage was 60-100% more than most, if not all, distros that I could find, upon booting just the desktop, mostly for these small apps that could very well be written in C.<br>
<br>If even Opera manages a lower memory footprint than browse(with more pages open), something can be done to improve browse - Opera is a more complex than browse will ever be - or need to be. At least to reduce the overhead of opening up one instance. Opening two didn't seem to bring much hurdle(which I find remarkable) but the initial overhead was too high.<br>
<br>Sugar terminal ~8s to load, Xfce Terminal ~2s, and one was spent mostly rendering the window, after it loaded.<br><br></div><div>
</div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"><br>
<div><br>
> when<br>
> people ask about how to fix things, the answers that keep coming back<br>
> all appear to be python related.<br>
<br>
</div>The whole system is in Python! Everything is going to be python-related!<br>
<div><br>
> so it's not FUD to say that the<br>
> dependance on Python is hurting performance.<br>
<br>
</div>It's not "FUD", but it's not exactly substantiated. We have some<br>
understanding of where we are spending our cycles, and it's not as simple<br>
as "in the python interpreter". For example, measurements of activity<br>
startup time indicate that we're spending a lot of time in SVG rendering<br>
and Cairo. This isn't too surprising, since Sugar uses SVGs much more<br>
intensively than most desktop environments, and often renders many<br>
different versions of the same icon for the purposes of recolorization or<br>
animation.<br>
<br>
There are certainly many improvements we could make to perceived speed.<br>
Some, like fixing upstream modules (e.g. dbus-python) not to do any<br>
computation at import time, are "python-related", though they have little<br>
to do with the language itself. Some, like switching to a better<br>
filesystem or testing LZO support in JFFS2, are entirely separate. Many,<br>
like rewriting the Journal GUI to minimize redrawing of widgets and enable<br>
smarter scrolling, are large projects.<br>
<br>
Blaming Python for our user-experience speed problems is not scientific,<br>
and it's not helpful. Have you found some critical piece of code that you<br>
can rewrite in C for speed? We'd love that.<br>
</blockquote><div></div><div>Would that be welcome?</div><div></div><div>Best regards,</div><div> Tiago Marques</div><div> </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
- --Ben<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.9 (GNU/Linux)<br>
<br>
iEYEARECAAYFAkmIyVUACgkQUJT6e6HFtqSgFgCfdmmKz5qoy7AdDw7XVq1lh0/t<br>
NmMAnij1vpH7oGOa/9h2z/fvrlP745gs<br>
=VpmM<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br>