What I find discouraging is mentally comparing the "responsiveness
in use" of F10-based Joyride builds against what I remember (perhaps
mistakenly) of responsiveness with Ship.2 builds. [I don't
currently have a Ship.2 system on hand for direct comparison.]
Examples of my ("non-performance") e
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
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 docum
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 wel
I'm
optimistic compositing hooks will be a huge win
Thanks,
Greg S
> Date: Wed, 31 Dec 2008 09:20:27 -0700
> From: Jordan Crouse
> Subject: Re: performance work
> To: l...@screamingduck.com
> Cc: devel@lists.laptop.org, g...@laptop.org
> Message-ID: <495b9bcb.2010..
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
Neil Graham wrote:
> On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
>>> I'm curious as to why reads from video memory are so slow, On standard
>>> video cards it's slow because there is quite a division between the CPU
>>> and the video memory, but on the geode isn't the video memory sha
On Tue, 2008-12-30 at 20:41 -0700, Jordan Crouse wrote:
> > I'm curious as to why reads from video memory are so slow, On standard
> > video cards it's slow because there is quite a division between the CPU
> > and the video memory, but on the geode isn't the video memory shared in
> > the same S
Neil Graham wrote:
> On Mon, 2008-12-22 at 15:36 -0700, Jordan Crouse wrote:
>
>> You might want to re-acquire the numbers with wireless turned off and
>> the system in a very quiet state. If you want to be extra careful, you
>> can run the benchmarks in an empty X server (no sugar) and save th
Jordan and Neil,
That's great work, thanks!
Eben, Neil and Sugar people,
Can you tell from the test descriptions below which of these operations
we are most likely to encounter in the XO GUI?
I think we can use the Cairo trace utility S found:
http://wiki.laptop.org/go/Performance_tuning#Othe
Hi Jordan et al,
Thanks a lot for the advice. I'm forking this thread and will reply on
the other one too.
One question here on your suggested methodology. Are you suggesting that
we try those X composite hooks and then re-run the benchmark to see if
it improves?
All,
Is anyone interested in
On Mon, 2008-12-22 at 15:36 -0700, Jordan Crouse wrote:
> You might want to re-acquire the numbers with wireless turned off and
> the system in a very quiet state. If you want to be extra careful, you
> can run the benchmarks in an empty X server (no sugar) and save the
> results to a ramfs ba
Greg Smith wrote:
> Hi Jordan,
>
> Looks like we made a little more progress on graphics benchmarking. See
> Neil's results below.
>
> I updated the feature page with the test results so far:
> http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
>
> What's next?
>
> Do we know en
Greg Smith wrote:
> Hi Jordan,
>
> Looks like we made a little more progress on graphics benchmarking. See
> Neil's results below.
>
> I updated the feature page with the test results so far:
> http://wiki.laptop.org/go/Feature_roadmap/General_UI_sluggishness
>
> What's next?
>
> Do we know en
ar section of the code for
optimization?
Thanks,
Greg S
***
Subject: Re: performance work
To: Wade Brainerd
Cc: OLPC Development , g...@laptop.org
Message-ID: <494e16aa.3070...@skierpage.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Wade Brainerd wrote
Wade Brainerd wrote:
On Tue, Dec 16, 2008 at 7:08 PM, Neil Graham Is there a build of cairo that can produce a log of what calls are used
> in typical XO use?
http://www.cairographics.org/FAQ/#performance_concerns says
"Cairo provides a cairo-trace utility (currently only available from t
On Tue, 2008-12-16 at 16:23 -0700, Jordan Crouse wrote:
> I recommend running the Cairo benchmarks on the XO again with
> acceleration turned off in the X driver. This will give you a good
> indication of which operations are being accelerated and which are not.
Done.
http://screamingduck.com
On Tue, Dec 16, 2008 at 7:08 PM, Neil Graham wrote:
> On Tue, 2008-12-16 at 16:23 -0700, Jordan Crouse wrote:
> > The first thing you need to do is determine which operations you really
> > care about. I would first target the operations that deal with text and
> > rounded corners, since those wi
On Tue, 2008-12-16 at 16:23 -0700, Jordan Crouse wrote:
> I would start by establishing a 1:1 baseline - it is great to compare
> against a 2Ghz Intel box, but that the differences between the two
> platforms are just too extreme. No matter how good the graphics gets,
> we are still constrain
Greg Smith wrote:
> Forwarding this to devel.
>
> Any comments or suggestions on how we can start to optimize graphics
> performance is appreciated.
That is a rather open ended question. I'll try to point you at some
interesting places to start with the understanding that not one thing
is goin
Forwarding this to devel.
Any comments or suggestions on how we can start to optimize graphics
performance is appreciated.
It looks like we have a good test bed in place which should help us
focus on the right bottlenecks.
Thanks,
Greg S
Greg Smith wrote:
> Hi Neil,
>
> That's great data, t
21 matches
Mail list logo