Re: Optimisation

[Roger H. <rog...@mi...>]

On Wednesday, April 7, 2004, at 07:25  am, Dair Grant wrote:

> 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.

Oops, I meant viewMode not viewState throughout my original e-mail. They
both get set at the same time and I clicked (and copied) the wrong one 
in the
source before pasting multiple times into the e-mail. I am not so 
sloppy when
I am programming I hasten to add.

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

Firstly the call to E3ClassTree_GetClassByType.
In immediate mode,  it gets moved into each of the routines which get 
vectored to.
In retained mode, it is unnecessary as we have theObject->theClass 
which is a
benefit of the optimisation I forgot about.

The switch is replaced by a jump via one of the function pointers. The 
calls
to E3ClassTree_GetMethod are in the routines jumped to. The default case
jumps to the 'BadMode' routine, though this seems hardly necessary as 
the
view mode is known to be only ever kQ3ViewModeInactive, 
kQ3ViewModeDrawing,
kQ3ViewModePicking, kQ3ViewModeWriting or kQ3ViewModeCalcBounds.
I retained it as I went for safety where it would not compromise speed 
in any way.

The test if  instanceData->viewMode == kQ3ViewModePicking is now
redundant as the picking routines knows it is true and the other methods
know it is false. The test of instanceData->pickDecomposeCount == 0
gets put into the picking routines, as does the call to 
E3View_PickStack_SaveObject.

The test of submitMethod and the subsequent call etc. get moved into 
each of
the routines we vector to.

The test if instanceData->viewMode == kQ3ViewModePicking is again always
true in the picking routine and false elsewhere so is redundant. The 
second test
of instanceData->pickDecomposeCount and call to 
E3View_PickStack_SaveObject
get moved into the picking routines, though I toyed with the idea of 
doing the test
only once and having 'then' and 'else' clauses which included the 
submitMethod test
and call, but I rejected this as I was not ABSOLUTELY sure that 
pickDecomposeCount
could not change in the submit method itself. I have not profiled 
picking as it is
reasonably fast, it was retained mode drawing I was speeding up and I 
wanted
to make sure nothing else was slower, and if possible, faster.

>
>> 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?

In only the retained mode render function as we know that the test of
instanceData->viewMode == kQ3ViewModeDrawing is false elsewhere
in retained mode, and that it is not needed in immediate mode. In the
source I sent you this is further optimised by a check to see if there
is a set on the object but I do not include that optimisation in this
set of changes.

> Perhaps I've misunderstood the change - is it in the set of source you
> sent me previously?

Yes. I think its my muddling of mode/state in the description which
is confusing you.

>  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?

No, a lot more than that. The switch, several tests, the call to
E3ClassTree_GetClassByType and for me it seems a lot cleaner
way of coding it, though there is nothing wrong with the original,
its just that things have got tacked on afterwards. When I step through
it whilst debugging, I keep thinking "Oh, get on with it, why is there
so much overhead before actually doing the real work?". The fact
that it shows up in 'Shark' is a good reason too!

Roger.