Re: Optimisation

[Dair G. <da...@re...>]

Roger Holmes wrote:

>In the current cvs source, TQ3ViewData has a field viewState which
>is used to switch into the appropriate piece of code whenever an
>object is submitted, including objects within groups in retained mode.
>..My version adds a pair of pointers to functions, one for immediate
>mode and one for retained mode. Whenever viewState gets changed
>then so do the two function pointers.

OK.


>e3view_submit_object disappears entirely and E3View_SubmitRetained
>and E3View_SubmitImmediate become simply calls to the appropriate
>function pointer. All the tests at the bottom of E3View_SubmitRetained
>are rolled into the routines which get vectored to. There are two for
>each value of viewState, including the 'Error' and 'BadMode' cases.

Not sure I follow this bit - e3view_submit_object currently switches on
viewMode rather than viewState, and also does some pre/post setup for
picking.

Where does that code get moved to, if e3view_submit_object is no longer
there?


>The benefits are faster execution, a simpler stack crawl when you are
>debugging. The only slight downside is that e3view_submit_begin is a
>little bit bigger and that there is no central submit routine where
>code could be placed.

Hmm, the retained path also has pre and post render callbacks to the
app, so do the get duplicated into the function pointers?

Perhaps I've misunderstood the change - is it in the set of source you
sent me previously? If so I'll take a read through it: to be honest it
sounds like a bit of a micro-optimisation though, i.e., we're removing
the overhead of calling e3view_submit_object but are still doing all the
same work - so the only thing that gets saved is the overhead of the
function call?


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/