Hi Greg,<div><br></div><div>I think there's actually a lot of overlap between activity performance work and OS performance work.</div><div><br></div><div>The bottlenecks I encountered and resolved were in PyGTK, Cairo, the Python interpreter, librsvg, etc.  These are the many of the same libraries which are believed to cause sluggishness in the core UI.  </div>
<div><br></div><div>Unfortunately, most of my performance success was had by replacing the aforementioned libraries with custom C++ extension modules.  Each time I remove some Cairo code and replace it with custom C++ code, the activity gets faster.  I wouldn't advocate the Sugar developers take that approach :)<br>
</div><div><br></div><div>-Wade<br><br><div class="gmail_quote">On Wed, Dec 31, 2008 at 4:01 PM, Greg Smith <span dir="ltr"><<a href="mailto:gregsmitholpc@gmail.com">gregsmitholpc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi All,<br>
<br>
Answering two e-mails on one pass.<br>
<br>
I agree, its hard work.<br>
<br>
Wade,<br>
<br>
I believe this thread is about optimizing the XO OS and GUI. That's why I call the requirement General_UI_sluggishness.<br>
<br>
Optimizing applications is yet another challenge. I'm all for people doing that hard work and documenting it so the next person doesn't have to re-invent the wheel. Your performance URL is already posted to the page in the "tools" section. Let me know if you have any other links (GIT URLs?) or e-mails I should make easily accessible.<br>

<br>
Michael,<br>
<br>
The performance goal I worked out with Eben is on the page already. It could be better but its a start.<br>
<br>
Lots of people have noticed.<br>
<br>
Neil and Jordan analyzed which Cairo calls are causing the most trouble and how long they take.  I also broke John's suggestions in to general areas: <a href="http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness" target="_blank">http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness</a><br>

<br>
Could use more editing (e.g. swap suggestions may belong in memory, file read/write caching should be added etc.).<br>
<br>
You're just scratcing the surface with BW, latency and "messages". CPU cycles, process priority, caching, bottleneck definition, instruction sets and compilers, word/block/sector size usage, and if you're really hard core rows and columns are all optimizable.<br>

<br>
If you have an algorithm improvement to offer, I'm all ears.<br>
<br>
When we have a critical mass of time from professional engineers we can improve performance. Until then it waits and the users wait too.<br>
<br>
Let's build on what we have, we're making progress.<br>
<br>
Thanks,<br>
<br>
Greg S<br>
<br>
****************<div class="Ih2E3d"><br>
<br>
On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:<br></div>
> The solution to the performance problems is good old fashioned elbow grease.... These are the sorts of things that we need to find and<div class="Ih2E3d"><br>
> squash - and yes, it will be very time consuming and a little boring.<br>
<br></div><div class="Ih2E3d">
Several anecdotes for your amusement and reflection:<br>
<br>
* When was the last time someone posted to devel asking: "what is the<br>
  right algorithm or datastructure for task ____?"<br>
<br>
* When was the last time someone publicly analyzed the upper or lower<br>
  bounds on the bandwidth, latency, or quantity of messages necessary to<br>
  accomplish task ____?<br>
<br>
* When was the last time that you published a performance goal for your<br>
  software? Did you hit it? Did anyone notice?<br>
<br>
Michael<br>
<br>
P.S. - Charles Leiserson once remarked that performance is like a<br>
currency which programmers trade for (all) other worthwhile things like<br>
schedule targets, scope of features, other resource consumption, various<br>
kinds of security, etc [1]. This suggests that one would do better to<br>
ask for performance or ____ but not both. Think of Blizzard.<br>
<br>
[1] <a href="http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/" target="_blank">http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/</a><br>
<br></div><div><div></div><div class="Wj3C7c">
Wade Brainerd wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with Jordan.  You just have to sit down and do the work to optimize<br>
the code, either finding the fastest path through hardware and software<br>
stack.<br>
I've rewritten Bounce twice now for performance just to hold on to 20fps on<br>
the XO.  Colors! has been through many performance iterations as well<br>
(compare v1 and v13 with large brushes).  I've just had my hat handed to me<br>
by Cairo for Typing Turtle as well (with the hand display enabled, you can<br>
type about 1WPM).  So I'm looking forward to rewriting my keyboard rendering<br>
to deal with that.<br>
<br>
If you have an issue with the performance of the XO, just spend the time by<br>
yourself to analyze it and fix it, talking about it accomplishes nothing.<br>
 If you find a solution that would help others, post it.<br>
<br>
-Wade<br>
<br>
</blockquote>
</div></div></blockquote></div><br></div>