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



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. I'll
look over everything you sent in closer detail when time permits, but a
couple of things jumped out at me immediately, and I'd love some
clarification if you have a chance. (Though this might ultimately also
be a question for Mike Gorse.)

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

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.

So I'm wondering:

1. Do you reliably get numbers more or less like the above each time
   you run your tests?

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?

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.

Thanks again for your work in this area! Take care.
--joanie

[1] http://git.gnome.org/browse/at-spi2-atk/commit/?id=d0f7dd49eebedc8c3993a116411f5a8320965968



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]