Lets say you have a method that is called hundreds of times a second
and its job is to write data to a variety of variables (ints, doubles,
strings, etc.). These values aren't needed after the method completes.

Would it be more efficient to keep member variables as part of the
class in which to insert the data? Or just declare local variables
inside the method each time its called? See the 2 examples below.


class thisClass {

public:
void callback() {
int varA;
double varB;
std::string varC;
varA = retrieveIntFromAnotherSource();
varB = retrieveDoubleFromAnotherSource();
varC = retrieveStringFromAnotherSource();

// do a bunch of calculations
}
};



class thisClass {

public:
void callback() {
m_varA = retrieveIntFromAnotherSource();
m_varB = retrieveDoubleFromAnotherSource();
m_varC = retrieveStringFromAnotherSource();

// do a bunch of calculations
}

private:
int m_varA;
double m_varB;
std::string m_varC;
};

On 2008-10-24 12:31:57 -0400, btmick said:

> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called?

Try it.

On Oct 24, 5:31 pm, btm...@gmail.com wrote:
>
> class thisClass {
>
> public:
> void callback() {
> int varA;
> double varB;
> std::string varC;
> varA = retrieveIntFromAnotherSource();
> varB = retrieveDoubleFromAnotherSource();
> varC = retrieveStringFromAnotherSource();
>
> // do a bunch of calculations
> }
>
> };

The obvious answer is that you got to measure the performance using
various optimization levels of your compiler to determine the answer.
The 'collect' tool on Solaris is very handy. Without such measurements
you might end up optimizing prematurely. Also if the above callback()
member function is not using any member variables (and its not
static), then why is it a member function? Also, it can be re-written
as

void callback() {
int varA = retrieveIntFromAnotherSource();
double varB = retrieveDoubleFromAnotherSource();
std::string varC = retrieveStringFromAnotherSource();
// do more
}

Just some issues to think about.

Rgds,
anna

On Oct 25, 2:31 am, btm...@gmail.com wrote:

You also can define variable with static modifier:

void callback() {
static int m_varA = 0;
m_varA = retrieveIntFromAnotherSource();
}

But do not call this method recursively or multithread.

btmick wrote:
> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called?

What does your profiler tell you?

I would expect little or no difference in performance for the primitive
types. It doesn't take any longer to set up a big stack frame than a
small one. If the values are really used so frequently that caching is
worthwhile, the compiler will cache them in registers, anyway.

The std::string might be worth keeping around, so that new allocations
from the free store are not necessary on every call to the function.
However, any portion of the string's memory that is not in continuous
use will be fallow.

On Oct 24, 3:31 pm, btm...@gmail.com wrote:
> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called?

The ater is preffered.you can also use declare static variables inside
your member function(method)if they are intentended to be private to
method while keeping their values for later calls to the function.

regards,
FM.

On Oct 24, 10:31 pm, btm...@gmail.com wrote:
> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called? See the 2 examples below.

My intuition says that it would be faster to define local variables.
I can even offer some logic behind this (better locality of
reference.)

**BUT** long and painful experience has taught me, that if you really,
really, have to care about this sort of optimization, the only way is
to try it and see.

(Actually, I would be very surprised if it made more than a few %
difference either way. If that's right, I don't think it would be
worth cluttering up the class with what are essentially local
variables.)

On Oct 24, 3:31 pm, btm...@gmail.com wrote:
[..]
> // do a bunch of calculations
> }
>
> private:
> int m_varA;
> double m_varB;
> std::string m_varC;
>
> };
>

Keep it local and on the stack. Member variables should be used for
storing state between member function calls. With local stack
variables the compiler will be given more opportunity to optimize
code. If you decide to multithread later your member variables will
have the problem of stomping on shared state my different threads.

On Oct 24, 6:31 pm, btm...@gmail.com wrote:
> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called?

Local variables are better. Reasons:

1) With local variables, the compiler knows that the content will be
discarded after the method call, which can help optimization.
Especially
its content do not need to be saved, so stored in memory. Best case
scenario: it will be completely used in a local register.

2) Stack memory is only allocated for the method call an the stack.
member
variables will be allocated for the entire life of the object, or even
the program for static variables.

terminator wrote:
> On Oct 24, 3:31 pm, btm...@gmail.com wrote:
>
> The ater is preffered.you can also use declare static variables inside
> your member function(method)if they are intentended to be private to
> method while keeping their values for later calls to the function.
>
> regards,
> FM.
>Another option is to use a static local variable. Being static means
that it will only be constructed on the first entry to the function.
Being local means that it will not clutter up external code. And
finally, the object will be destroyed when the program ends.

On Oct 24, 5:31 pm, btm...@gmail.com wrote:
[..]
> // do a bunch of calculations
> }
>
> private:
> int m_varA;
> double m_varB;
> std::string m_varC;
>
> };
>

I think it would be better to keep the variables as the part of class
than declaring them in a function(here "callback"). The reason is that
there is an extra over head in creating these variables on stack
whenever this function is called in second example.

- Bharath

On Oct 24, 6:31 pm, btm...@gmail.com wrote:
<snip>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called? See the 2 examples below.

The answer (of course) is to profile. There are too many assumptions
to be made. Which compiler and which platform? Will the next version
of the compiler be different? I've been surprised in the past.

>
> class thisClass {
>
> public:
> void callback() {
> int varA;
> double varB;
> std::string varC;

You pay for a ctor and dtor every time through this. You don't with
member vars.

> varA = retrieveIntFromAnotherSource();
> varB = retrieveDoubleFromAnotherSource();
> varC = retrieveStringFromAnotherSource();

Of course if you were after efficiency you would write
std::string varC( retrieveStringFromAnotherSource() );
[..]

On Oct 24, 8:31 pm, btm...@gmail.com wrote:
> Lets say you have a method that is called hundreds of times a second
> and its job is to write data to a variety of variables (ints, doubles,
> strings, etc.). These values aren't needed after the method completes.
>
> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called? See the 2 examples below.

The question should not be witch is "faster" for this depend on
several things that you have little control over, like compiler
optimization or in this case standard library implementation. I think
that the best answer is witch of the two better communicate your
intentions, both to other programmers and to the compiler. If you're
not using the variables after the calculation then simply use local
variables, this will make it clear that those are not used anywhere
else. The compiler could optimize the int into a register, for
instance, and another maintainer in the future will be able to change
one of those vars without having to search the rest of the
implementation for other uses of the those.

On Oct 24, 4:31 pm, btm...@gmail.com wrote:
> Lets say you have a method that is called hundreds of times a second

this sounds like some kind of DSP work?


> Would it be more efficient to keep member variables as part of the
> class in which to insert the data? Or just declare local variables
> inside the method each time its called?

I have exactly the same situation in my audio work although the method
that gets called processes a 'block' of data. by a block I mean it
doesn't just return one float or double or int rather it fills an
array of say, 64, 128 or 256 values.

if this is how you are doing things then definitely try using local
variables as I have found there to be a small decrease in CPU usage.
in my audio the number of methods called depends on what the user is
doing (number of musical notes being played etc) so a small CPU
decrease could easily be multiplied by a factor of 20-30. obviously
you store anything you need for the next call in member variables. I
have seen this approach in use in high quality, open source audio
software.

maybe that helps.

Francis Glassborow <francis.glassborow> wrote in
news:0uidnZEkzqMVL5jUnZ2dnUVZ8tfinZ2d:

> Another option is to use a static local variable. Being static
> means that it will only be constructed on the first entry to the
> function. Being local means that it will not clutter up external
> code. And finally, the object will be destroyed when the program
> ends.
>

I think a word of caution is also warranted in connection with
this suggestion: the static local variable will be shared by method
calls across all instances of the class, which is different behaviour
than a local automatic or a member variable.

MV