Remote call horror show

Hi,

While experimenting with the UNO accessibility tree, I found that
walking the tree from (out of process) Python was slower than it had
any right to be. To investigate why that might be, I wrote a simple
benchmark:

# ... setup ...
ac = doc.CurrentController.ComponentWindow.AccessibleContext
for i in range(1000):
        ac.getAccessibleChild(0)

and then hit it with callgrind, and later some manual instrumentation.
Logically, you would expect the number of remote calls over the UNO
bridge that result from this would be in the region of 1000, charitably
give or take a factor of two or so.

The actual number was 57,000, which pretty perfectly explains why it
was so slow.

The main reason for this seems to be the silly amount of up-front work
done by com.sun.star.script.Invocation, which ends up performing dozens
of queries for interfaces which will in most cases never be used on each
object returned from a UNO call over the bridge.

By performing these queries when needed:
  https://gerrit.libreoffice.org/#/c/16780/
the number of calls made by the above benchmark falls to a much more
manageable 7000, and the time to run the more realistic test which
originally sparked this search also fell by 3/4.

Could anyone with more UNO knowledge than me comment on whether the
approach of the above patch is reasonable?


Having said all that, the time to run the test in question is still too
high, and the ultimate solution may well be to merge what I'm doing into
unotest and take advantage of the speed gain of running the whole thing
in-process. It complicates matters slightly that LO crashing then wipes
out the Python process as well, but being able to run more tests at
greater speed should make up for this.

Regards
Matthew Francis