GNOME Bugzilla – Bug 117072
Object hierarchy traversed 6 times
Last modified: 2004-12-22 21:47:04 UTC
I ran gok and yelp. In gok I chose Activate and then chose the yelp window. The children of a particular object in yelp were got 6 times. This seems to be because gok requested them.
Created attachment 18180 [details] Stack traces when gok_spy_has_child is called
There are certainly optimizations that can be done in gok-spy. One thing we don't want to maintain is any off screen model (which we modify based on events). But traversing a subtree several times is wasteful, I think using bitflags for both a role type in variable and for a return out variable might be a way to go. Currently gok traverses looking for a menu, traverses again looking for a toolbar, and again looking for buttons... it all depends what branch keys are on the current keyboard. (all three of these happen to be on main) All this validation of dynamic branch keys is triggered by focus events.
Good catch. This is an important one, especially for things like StarOffice. Optimizing for a single (or perhaps at most two) tree traversal is probably one of our highest priority performance bugs.
yes, this is a known issue. Fixing it will require some redesign and should wait post-2.4.
BTW I am not sure bitflags in the params are the most attractive solution; OTOH they can be returned in the gok-specific structs returned in the object list built by gok_spy_find_children et al. Perhaps we need a gok-specific GokComponentMatchCondition struct to build and pass in.
I can take this one as time permits.
Something like the "GokComponentMatchCondition" does sounds attractively flexible.
OK, I will plan to work on this next week (i.e. end Sept. 2003)
before I commit changes, can we come up with a good 'test case' for a benchmark (that's currently too slow), so we can assess whether/how much we improved things? maybe you could do that David... :-) ?
maybe - but ideally we need a dedicated machine for that... is there such a beast over there?
Actually perhaps Malte Timmermann could give us a good Star Office test case... Also, David Hawthorne has posted related java slowness issues I think...
I don't think we need a 'dedicated machine' - we just need a specific test case with benchmark timings on a specific architecture, i.e. "operation foo took 23.56 seconds on a 400 MHz sparc Ultra 10" or "ditto on a 600 MHz PIII with 256MB RAM" (assuming a few things like no swapping, and using the second invocation of a run to minimize paging-related issues) The benchmark doesn't have to be terribly formally exacting I think, just a specific operation. Probably we need to add some timing blurbs to GOK or gok_log once we agree on the operations which are the most annoyingly slow.
adding accessibility keyword
bumping up priority as this is a serious performance issue for some applications (for instance StarOffice).
I'll start on this one next week (W/E Nov 21).
Created attachment 21898 [details] [review] initial patch for this problem (review - not suitable for commit)
adding PATCH keyword - but bear in mind that the patch isn't yet ready to apply.
Wow. Quite the patch. If you are still having bugs with it, don't forget you can build with the --enable-logging-normal and --enable-logging-exceptional flags to get some human readable trace messages... The trace can often be very revealing.
Created attachment 22218 [details] [review] latest patch against gok HEAD
Created attachment 23066 [details] [review] latest patch, with previous major issues resolved. Ready to commit after removal of debug output?.
spoke too soon, this patch still has major issues.
Created attachment 23541 [details] [review] final patch as committed, except for ChangeLog entry.
Fixed in CVS! David Hawthorne, could you test this against the former benchmark for StarOffice to see how much this impacts the performance issue? Maybe you'll need to re-benchmark before updating GOK and running it (with this new code). This patch was very big, and I haven't tested really hard since finding the main bug that was offending, so hammering on the new GOK code to see if it's robust is probably a good idea.