Re: [g-a-devel] At-spi2-atk performance tests
- From: Alejo Pacín Jul <apacin igalia com>
- To: Joanmarie Diggs <joanied gnome org>, gnome-accessibility-devel gnome org, Alejandro Piñeiro <apinheiro igalia com>
- Subject: Re: [g-a-devel] At-spi2-atk performance tests
- Date: Mon, 12 Sep 2011 14:26:24 +0200
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]