Re: Optimization ideas (was Re: 64 bit version of Quesa)

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

On 24 Feb, 2007, at 03:11, James Walker wrote:

> Roger Holmes wrote:
>
>> More optimisation. Especially I would like to reduce going all
>> around the houses for a group to submit the groups within it.
>> One recursive routine in the stack trace is unavoidable, but at
>> the moment we have three routines repeatedly calling each
>> other. One knows what the submission mode is e.g Picking
>> but the other ones keep checking the mode, which must be
>> slowing us down. There has got to be a better way.
>
>
> I'm not sure which 3 routines you're talking about here.  When you
> submit a group for rendering, the call stack looks something like
>
> Q3Object_Submit
> E3Object_Submit
> E3View_SubmitRetained
> e3view_submit_retained_render
> e3group_display_submit_contents
> e3group_submit_contents
> Q3Object_Submit

Yes, in the debugger that's right. If you compile a version for  
profiling
(names on, optimisations on), then profile it with Shark, only three
of these show up. I guess some get optimised out. As far as optimisation
goes then it is just the three which matter, but of course it would be
nicer when debugging to not have all of these calls showing up.



>
> I say "something like" because if you subclass the view object, as  
> Geom
> Test does, you have the subclass submit-retained-render method in  
> there.
>   It's true that two of these, e3group_display_submit_contents and
> e3group_submit_contents, check the view mode, but  
> E3View_GetViewMode is
> just an accessor and should be quite fast.

But there's the switch statement. There is the call to  
E3DisplayGroup::GetState,
there is the checking of its success/failure, and it only ever  
returns success.
There is loads of code which does nothing constructive towards  
getting the
rendering/picking or whatever done, its just administrative red tape.

>
> One way I see to shorten the cycle is to have e3group_submit_contents
> call E3View_SubmitRetained directly instead of calling  
> Q3Object_Submit.
>   That looks safe, so I'll go ahead and commit it.

Yes that's a step in the right direction.



>
> Also, is anyone using kQ3CallbackElementTypeBeforeRender and
> kQ3CallbackElementTypeAfterRender, which are checked every time  
> through
> e3view_submit_retained_render?

Not me either.

> I put those in a few years back, but I don't use them any more, as I
> decided that I can do more with less trouble by subclassing the  
> view object.

Sounds good, I was thinking about having one set of routines for when  
there
was one and another set for when there wasn't, but if we can get rid  
of them
completely then thats even better.


How about this:

e3group_display_metahandler returns the same routine for the four  
instances
		case kQ3XMethodTypeObjectSubmitBounds:
		case kQ3XMethodTypeObjectSubmitPick:
		case kQ3XMethodTypeObjectSubmitRender:
		case kQ3XMethodTypeObjectSubmitWrite:

These could be four separate routines, call them
e3group_display_submit_contents_Bounds
e3group_display_submit_contents_Pick
e3group_display_submit_contents_Render
e3group_display_submit_contents_Write
These would know the view mode and so would
not have to get it or switch on it.

Roger.