performance work

[Wade Brainerd]

Hi Greg,
I think there's actually a lot of overlap between activity performance work
and OS performance work.

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.

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 :)

-Wade

On Wed, Dec 31, 2008 at 4:01 PM, Greg Smith <gregsmitholpc at gmail.com> wrote:

> Hi All,
>
> Answering two e-mails on one pass.
>
> I agree, its hard work.
>
> Wade,
>
> I believe this thread is about optimizing the XO OS and GUI. That's why I
> call the requirement General_UI_sluggishness.
>
> 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.
>
> Michael,
>
> The performance goal I worked out with Eben is on the page already. It
> could be better but its a start.
>
> Lots of people have noticed.
>
> 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:
> http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
>
> Could use more editing (e.g. swap suggestions may belong in memory, file
> read/write caching should be added etc.).
>
> 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.
>
> If you have an algorithm improvement to offer, I'm all ears.
>
> When we have a critical mass of time from professional engineers we can
> improve performance. Until then it waits and the users wait too.
>
> Let's build on what we have, we're making progress.
>
> Thanks,
>
> Greg S
>
> ****************
>
> On Wed, Dec 31, 2008 at 09:20:27AM -0700, Jordan Crouse wrote:
> > The solution to the performance problems is good old fashioned elbow
> grease.... These are the sorts of things that we need to find and
> > squash - and yes, it will be very time consuming and a little boring.
>
> Several anecdotes for your amusement and reflection:
>
> * When was the last time someone posted to devel asking: "what is the
>  right algorithm or datastructure for task ____?"
>
> * When was the last time someone publicly analyzed the upper or lower
>  bounds on the bandwidth, latency, or quantity of messages necessary to
>  accomplish task ____?
>
> * When was the last time that you published a performance goal for your
>  software? Did you hit it? Did anyone notice?
>
> Michael
>
> P.S. - Charles Leiserson once remarked that performance is like a
> currency which programmers trade for (all) other worthwhile things like
> schedule targets, scope of features, other resource consumption, various
> kinds of security, etc [1]. This suggests that one would do better to
> ask for performance or ____ but not both. Think of Blizzard.
>
> [1] http://www.catonmat.net/blog/mit-introduction-to-algorithms-part-one/
>
> Wade Brainerd wrote:
>
>> I agree with Jordan.  You just have to sit down and do the work to
>> optimize
>> the code, either finding the fastest path through hardware and software
>> stack.
>> I've rewritten Bounce twice now for performance just to hold on to 20fps
>> on
>> the XO.  Colors! has been through many performance iterations as well
>> (compare v1 and v13 with large brushes).  I've just had my hat handed to
>> me
>> by Cairo for Typing Turtle as well (with the hand display enabled, you can
>> type about 1WPM).  So I'm looking forward to rewriting my keyboard
>> rendering
>> to deal with that.
>>
>> If you have an issue with the performance of the XO, just spend the time
>> by
>> yourself to analyze it and fix it, talking about it accomplishes nothing.
>>  If you find a solution that would help others, post it.
>>
>> -Wade
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20081231/62ee6acc/attachment.html>