Where olpc machine spending time when using web broswer

[Carl Worth]

[Pardon me for quoting several separate messages in a single reply
here---I wasn't previously on this list, and it's difficult enough to
fish out the Message-ID of a single message to try to get a properly
formatted reply.]

On Mon, 2007-02-12, William Cohen wrote:
>    samples|      %|
> ------------------
>      19279 50.6077 vmlinux-20070309.olpc1p.dc5079fafb767e4
>      11959 31.3926 Xorg
>       6177 16.2147 python

The rest of the thread talked plenty about the Xorg samples. But
am I reading correctly that oprofile only sees 31% in Xorg and 50% in
the kernel? Does anyone know what's happening there? And shouldn't
that stuff be an important priority?

On Tue, 2007-03-03, Adam Jackson wrote:
> > On Mon, 2007-03-12 at 18:59 -0400, William Cohen wrote:
...
> > 6514     68.1096  libfb.so                 fbFetchTransformed
>
> Wow.  I think that's the first time I've ever seen this actually show up
> on a profile.  I didn't think anything used Render's transformations on
> account of they're so painfully slow.

But it's a new, cairo world now, Adam, and we prefer to use Render
whenever possible. So I expect you'll be seeing these paths in the X
server get exercised more and more, so we really do need to improve
this software to be much faster, (and also use the GPU whenever
possible to avoid this software altogether--obviously not an option on
the OLPC machine).

On Tue, 2007-03-13, Dan Williams wrote:
> On Mon, 2007-03-12 at 18:59 -0400, William Cohen wrote:
> > 613       6.4095  libfb.so                 fbFetchPixel_x8r8g8b8
> > 446       4.6633  libfb.so                 fbCompositeSolidMask_nx8x0565mmx
> > 252       2.6349  libfb.so                 fbStore_r5g6b5
> > 169       1.7670  libfb.so                 fbRasterizeEdges
> > 137       1.4325  libfb.so                 fbCompositeSrc_8888x0565mmx
>
> This one is inevitable since we're running in 565 and you have to do
> compositing and pixelsmashing to convert 8888 -> 0565.  However, could
> you get some idea of which lines are hot in this function?

It may be inevitable to do some conversion somewhere, but it's
definitely not inevitable that this should show up in profiling,
(though, we're talking less that 10% of 30% here, right?). But anyway,
since your destination format is 565 you should be ensuring that
you're getting your source images to 565 surfaces as soon as possible,
(convert on load, and never again after that).

Some things that can help with that are to load originally into a
surface without an alpha channel if there's no alpha in your image. Or
if there is alpha in the image, flatten as soon as possible,
(presumably, the background is often a known solid color, so hopefully this
would be possible quite early).

But maybe that's already happening here---like I said, these don't
look like big percentages here...

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20070315/8e6c5d20/attachment.sig>