Re: [g-a-devel] Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

[Piñeiro <apinheiro igalia com>]

On 11/05/2013 12:58 AM, Magdalen Berns wrote:
> Would need to be replaced by
>   selection = accessible.get_selection_iface()
>   if (selection):
>        <get the selected object using the selection interface> 
>   else:
>     <use a fallback to get the selected object>
>
> * Registry.registerEventListeners allow to register more than one event
> on one call.
> * All the utility methods at utils.py
> * etc
>
> Thanks! I think something similar was done to make the javascript
> bindings work because the name's of some of the interfaces (and maybe
> their methods - I can't remember off the top of my head) could not share
> the same names as those already existing in gnome-shell javasscript.

As you said that you didn't remember, this is the commit you are talking
about:
https://git.gnome.org/browse/at-spi2-core/commit/?id=5b9c1723

And that change was possible because there wasn't any other app using
atspi javascript bindings, and because we had the manually created
python bindings. That is basically a big API change, but Orca was not
affected because it was manually wrapped.
 
> > As far as I know, the only surprise that the author found, was that DBUS
> > was event slower than expected. But in any case, he was already waiting
> > DBUS being slower.
> It was a bit more than that, but my main point was that taking errors
> into account should explain surprises. i.e. if the results are
> surprising the experimental method is likely to be flawed.

Well, probably it is a subjective opinion, but I don't agree. Take into
account the abstract of his analysis:

"I have been under the impression that the CORBA IPC/RPC mechanism used by
the GNOME desktop environment was bloated and slow. People have
commented that the DCOP and
DBUS were speedier alternatives."

So he thought that DBUS was faster than DBUS. And he did all those
experiments to confirm that theory. And this was his conclusion:

"For repeated calls to a particular RPC function, the C bindings to the
Orbit2 orb outperform calls using
the C++ bindings to DCOP and DBUS."

So the surprise came from the fact that the empirical tests showed that
he was wrong on his initial assumption, not because the experiment
itself was wrong.

Having said so, we also need to take into account that those tests are
giving a really narrow perspective of the performance hits. It is only
measuring common methods of the accessibility framework individually, in
order to directly measure the performance of CORBA vs DCOP vs DBUS. But
as I said on my previous email, a good test suite should also analyze
which and how many times those accessibility methods are called.

> 7. Actual codes get written to implement changes decided in 6.
> > This is not clear. As I said, one of the ideas of measuring, is testing
> > a possible change.
> I just meant at that stage people would finally be able to act on the
> information discovered by taking tests and analysing the results.
> Essentially what I was driving at was that without the information there
> is nothing anyone can be sure of so it is probably worth answering the
> questions and, if that can be done sooner rather than later it may be
> worth it in the long run. 

Then we are at a egg-chicken problem. You are saying that without
answering the questions, we can't measure. I'm saying that I would like
to use the measures to found where are the possible problems, so questions.

Because in sort this is the situation:

Problem: some people thinks that GNOME accessibility framework
performance should be better.
Hypothetical solution: improve the performance of the current
performance bottlenecks.
Question: where are those bottlenecks?

My suggestion was using something similar to what was done in the past
[1] to found those bottlenecks, and the use that test suite to ensure
that we don't regress on any future change. Using the same scheme:

Problem2: we want to improve the GNOME accessibility framework API
Hypothetical solution2: there are two possible APIs
Question2: is API1 worse that API2 in terms of performance? Is any of
them worse to current state?

BR


[1]
https://wiki.gnome.org/Accessibility/Documentation/GNOME2/ATSPI2-Investigation/IPCResults



-- 
----
Alejandro Piñeiro