[g-a-devel]Re: performance tracing ...

[Bill Haneman <bill haneman sun com>]

Hi Michael:

Thanks for having a look at initial performance profiling for
gnopernicus (and at-spi, to some extent).

I agree with you about the gconf usage, of course, and the mouse events;
actually I think that an application concerned with performance would do
better to avoid using at-spi for mouse motion notification, and just go
straight to X; the exception being that building a good polling
algorithm is not trivial, and mouse grabs can interfere with apps that
need 'global' mouse notification.

(Certainly checking the role on the source of mouse events seems
unnecessary.)

> ...

> 	Making one wonder about the usefulness / wisdom of the 'isAFoo'
> methods.

I think they are useful, but certainly they shouldn't/needn't be used
just prior to 'getFoo' since 'getFoo' will answer the question for you
;-)


> 	Then of course - there is the tragedy of the StateSet interface:

Ah.  Well, there may be issues with further opaqu-ifying of this
interface, since it has to be workable without the cspi bindings (and
because of related language-binding issues that came up in ATK for
statesets).  There are reasons why a StateSet is a server-side object,
not just a data struct.

However, clients should not be calling state->contains() multiple times
when doing comparisons; they should, in order to compare complex states,
be using the 'compares' and 'equals' API which we have provided for this
purpose.  As you point out, if the statesets are in different
applications you lose efficiency.

> 	This interface needs junking completely - there is hope for that of
> course; 

I don't see how, since this API is now frozen and we can't just wrap it
away on the CSPI side.  We can consider our options for additional IDL
in 2.4

> we could make the 'getStateSet' API just do a 'getStates' and
> then implement all the methods as children of a purely local state set.

see above.

> [ anyone polling on a state-set to wait for a change needs shooting
> anyway ]. 

Truly, that would be nuts.

> So with that we could save another scad of calls [ and notably
> 200ms for the above call set (a pretty bad one but ...) ].
> 
> 	I think if we do that - we'll get an extremely snappy system which'll
> be a pleasure to use :-) [ at least on a fast machine ].
> 
> 	Is there any controversy there ? and/or problems ? I think a small
> amount of work on caching would do wonders for performance, although
> changing the way the StateSet works will provide by far the biggest win
> - I think that's the no. 1 performance killer.

I don't think we can or should touch this until 2.2 is complete.

- Bill

> 	HTH,
> 
> 		Michael.
-- 
Bill Haneman <bill haneman sun com>