Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 8:31 AM, Lars Kyllingstad
<pub...@kyllingen.nospamnet> wrote:
I have some functions for which I want to find the nicest possible
combination of performance and usability. I have two suggestions as to how
they should be defined.
"Classic" style:
real myFunction(real arg, int someParam, inout real aReturnValue)
{
declare temporary variables;
do some calculations;
store a return value in aReturnValue;
return main return value;
}
The user-friendly way, where the function is encapsulated in a class:
class MyFunctionWorkspace
{
declare private temporary variables;
real anotherReturnValue;
this (int someParam)
{ ... }
real myFunction(real arg)
{
do some calculations;
store a return value in aReturnValue;
return main return value;
}
}
I'm sure a lot of people will disagree with me on this, but let me first say
why I think the last case is more user-friendly. For one thing, the same
class can be used over and over again with the same parameter(s). Also, the
user only has to retrieve aReturnValue if it is needed. If there are many
such "additional" inout parameters which are seldom needed, it gets tedious
to declare variables for them every time the function is called. I could
overload the function, but this also has drawbacks if there are several
inout parameters with the same type.
My questions are:
- If I do like in the second example above, and reuse temporary variables
instead of allocating them every time the function is called, could this way
also give the best performance? (Yes, I know this is bad form...)
...or, if not...
- If I (again in the second example) move the temporary variables inside the
function, so they are allocated on the stack instead of the heap (?), will
this improve or reduce performance?
I could write both types of code and test them against each other, but I am
planning to use the same style for several different functions in several
modules, and want to find the solution which is generally the best one.
Any gains you get from skipping the initial calculations will be
swiftly cut down by the cost of heap allocation and cache misses, if
you allocate this object several times.
A much better way to get the usability of the latter with the better
performance of the former is to use a struct instead of a class. I
highly doubt you'll be needing to inherit these "operation objects"
anyway. The struct will be allocated on the stack, and you still get
all the usability.
Why not use scope to allocate the class on the stack?
For everything else, I agree with Donald Knuth (if he really said that...)