Mike Gorse <mgo...@alum.wpi.edu> wrote: > AT-SPI was originally designed around CORBA, specifically ORBit. Its > use led to a large amount of inter-process communication. Method > calls in ORBit were fairly quick, so this was not a huge problem, > although that isn't to say that there were never performance issues. > However, ORBit was deprecated for GNOME 3, and Codethink undertook > an investigation of the feasibility of porting AT-SPi to D-Bus. Note > that the D-Bus libraries were not really designed to be used in > cases where a large amount of synchronous method calls are needed. > Nevertheless, Codethink undertook an investigation of the > feasibility of porting AT-SPI to D-Bus. Their main conclusions were > that, although D-Bus method calls are slower than the equivalent > CORBA calls, a lot of AT-SPI traffic generated by Orca comes from a > handful of method calls--calls to fetch an object's name, parent, > children, or state set, for instance. If these data could be cached, > then a significant amount of traffic would become unnecessary.
How will this performance analysis change when/if DBus is implemented in the Linux kernel? The module for doing so already exists; it is currently under development by experienced kernel authors, with the intent to merge it into the mainline. Apparently, it's much faster than the current implementation. _______________________________________________ gnome-accessibility-devel mailing list gnome-accessibility-devel@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel