RE: Is OO a deliberate fraud?

["Ruth Ivimey-Cook" <Ruth.Ivimey-Cook@xxxxxxxxxx>]

Larry,

> > The side-effect free stuff is all very well, but it can lead to very
> > cluttered code and also, potentially, very inefficient code.
> 
> Cluttered, maybe, but I don't see why it has to be inefficient --- the
> channel just gets copied into a local variable, surely... And I really
> don't even see cluttered. The HOSTIO and STREAMIO code in the occam
> toolset never impressed me as cluttered, but it used a global channel of
> just the sort I'm thinking of.

It's ineffecient because for every call you make you've got to fetch the
parameters from the global/local location and put it in the appropriate
place for the calling convention being used - typically a register,
sometimes a stack; in the array and variable-checked occam style you might
also have to do one or more array accesses and also range check array
references.

So for a two parameter (in & out) channel bundle we've got between 2 (two
globals to register) and 8 (checked array access using a variable index)
independent memory accesses per call in overhead. Now, in graphics code
where you're interested in good performance, that is a significant issue.

If you postulate that the API call you're making actually uses those
channels inside internal routines that do the drawing, you're multiplying
that cost up; probably 2 or 3 accesses per call.

In academia raw performance might not matter; in industry it most certainly
does.

> > In can make it hard to maintain.
> 
> Were HOSTIO and STREAMIO hard to maintain?

IME, Yes.

Regards,

Ruth