Re: [g-a-devel] At-spi2-atk performance tests

[Alejo Pacín Jul <apacin igalia com>]

On 09/09/2011 10:55 PM, Joanmarie Diggs wrote:
> Hey Alejo.
>
> First of all, let me say "thanks!" for doing this. Having a means to
> quantitatively assess the impact of various changes (patches,
> enabling/disabling AT support and/or an AT) is of tremendous help.

It's nothing. ;-)

>   I'll
> look over everything you sent in closer detail when time permits, but a
> couple of things jumped out at me immediately

I know. Let me say "welcome to the boat"!

> , and I'd love some
> clarification if you have a chance. (Though this might ultimately also
> be a question for Mike Gorse.)

No problem!

> My understanding of the purpose of the commit you are examining [1] is
> to address the following problem: The mere act of enabling Accessibility
> support has a sizable, negative impact on desktop performance. This
> should not occur -- ideally not ever, but in the interim we can at least
> make it so that it doesn't occur when no ATs are running.
>
> Operating under that understanding I'd expect to see something like this
> for Rhythmbox:
>
>          Acc. Disable    Acc. Enable
> Before     2.23          39.83
> After      2.23           2.23
>
> In other words I wouldn't expect to see any before/after difference when
> Accessibility support is disabled, because the fix is supposed to
> address what happens when Accessibility support is enabled (but no ATs
> are running).

All right!

> However, it appears we picked up a benefit along the way. Awesome! I'll
> take it. :-) But then I would still expect to see something like:
>
>          Acc. Disable    Acc. Enable
> Before     2.23          39.83
> After      2.01           2.01
>
> But what we see is:
>
>          Acc. Disable    Acc. Enable
> Before     2.23          39.83
> After      2.01          18.36
>
> Thus the fix does seem to have brought about much positive change, which
> is terrific. And yet going from 2.01 to 18.36 when accessibility support
> is merely enabled but not actually being used still seems like it might
> be a non-trivial negative performance hit.

Yes, it's just as you say.

> So I'm wondering:
>
> 1. Do you reliably get numbers more or less like the above each time
>     you run your tests?

Yes, always more or less the same.

> And if so:
>
> 2. Have you tried running the tests in a non-tree widget, say, like
>     examining text-changed events in Gedit? Do those numbers look more
>     like the tree numbers or more like my "this is what I'd expect" fake
>     numbers?

No, I've not tried running the tests in a non-tree widget. Talking about 
the tests with Alejandro, we agreed that the tests will be executed by 
keeping the environment in which problems were detected (trying to 
reproduce them). So, I've used same apps and settings.

So, the results can be regarded as "the worst possible case" results (I 
understand we agree that a huge tree view is the worst possible case).

> As you no doubt have seen and heard, treeviews are evil beasts when it
> comes to enabling Accessibility support. So that is what we should focus
> our attention on. But from the resulting numbers (e.g. 2.01 ->  18.36) it
> seems hard to know if what we are seeing is special treeview evilness of
> some sort, or if there are additional areas in the ATK bridge to be
> disabling event handlers.

I understand. So, I'll talk with Alejandro to see how we will approach 
this. Tests are written for generic apps, so it's very easy to change 
them to use other apps or settings. I'm thinking of trying them with 
Nautilus in icon view mode to see the difference, for example (I'm not 
sure now if I can do the same with Rhythmbox).

BTW, into Sysprof outfiles, is possible to see in detail what is 
consuming so many resources and treat it as an outlier (and exclude it 
from the total count) or, even, try to fix it.



Best regards,

                        Alejo Pacín.