> The 'loan' concept is to handle references efficiently that we receive > during an event emission (AFAIR) - that is more cunning ;-) the basic > problem is we get a lot of events containing references which are 'live' > only for the lifetime of the synchronous event emission, but we don't > want to take a ref on all of them so we do: > > IPC libspi client > -> incoming event > create 'borrowed' reference > -> on to libspi client code > a) client code does a ref ... > <- > b) check reference - did it get reffed ? > yes -> convert to a permanant ref > ref <- > > As you see if a) does not occur, b) does not need to either and we save > a round-trip 'ref' call per event emission.
In pyatspi we are currently not taking advantage of this optimization, when we receive an event, all remote objects in the event's structure are referenced, so basically we get up to 2*3 extra round trips for each event we receive (event.source, event.host_application and event.any_data). I have an ugly patch sitting in bugzilla that assures we only ref objects that we are holding a reference to after the event callback returns: http://bugzilla.gnome.org/show_bug.cgi?id=502924 It depends on weak reference support for pycorba objects. I put that in pyorbit's trunk recently: http://bugzilla.gnome.org/show_bug.cgi?id=502925 I am not completely convinced it is giving us a real performance boost, for two reasons: 1) I don't know what kind of perf overhead my cruddy patch has, even though the wire traffic is lessened. 2) Since our system is synchronous, most applications (like Orca) will choose to decouple the event handling by queuing, and hold references to the event's remote objects after the callback returns, so a ref() is done in most cases. Nonetheless here are some numbers on a short automated UI test with Orca: Call Trunk Patched Unknown.unref 2803 754 Unknown.ref 1181 232 So bottom line, the loaning thing is cool, but we haven't been using it correctly until now. Cheers, Eitan. _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
