static variables and performance

[Grahamo]

Hi,

I have a a routine that is frequently called. It simply iterates over a
list of dates and does some sanity checking. The following pseudo code
summarises it.

void check()
{
const Date someDate = 1/1/2005;

for (each item)
{
process(item);
}
}

The above routine is called quite frequently.
My question relates to the construction of the Date object above. It's
constructor doesn't incur any great overhead however I'm curious to
know whether I should make it static. By doing that I'll obviously
call its constructor just once and will therefore save some time at
that point, but I'm wondering about the runtime overhead of using a
static? Is there a downside? This isn't a big issue at all, I'm just
curious to know whether it would be better declared as static or
constructed each time I invoke the routine.

Any opinions? Silly question.... there's *always* opinions on this
group :)
thanks and have a nice day

G

[benben]

"Gr*****@nospam.com" <Gr**********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

Hi,

I have a a routine that is frequently called. It simply iterates over a
list of dates and does some sanity checking. The following pseudo code
summarises it.

void check()
{
const Date someDate = 1/1/2005;

for (each item)
{
process(item);
}
}

The above routine is called quite frequently.
My question relates to the construction of the Date object above. It's
constructor doesn't incur any great overhead however I'm curious to
know whether I should make it static. By doing that I'll obviously
call its constructor just once and will therefore save some time at
that point, but I'm wondering about the runtime overhead of using a
static? Is there a downside? This isn't a big issue at all, I'm just
curious to know whether it would be better declared as static or
constructed each time I invoke the routine.

Any opinions? Silly question.... there's *always* opinions on this
group :)
thanks and have a nice day

G

I'm not an expert on static constructors but I think it simply doesn't exist
:-) Or maybe I misunderstood your quest, and let me know if it is true.

What I guess what you are asking is if we can construct something like the
following:

class Date
{
public:
static Date() // constructor
{
// once and for all...
}
};

The above code simply doesn't compile. And also, I don't seem to understand
your pseudo code. Why do you need a Date object to check other Date objects?

Ben

[Srini]

*Ben

May be he meant to make the local 'someDate' static...

Srini

[Ian]

Gr*****@nospam.com wrote:

Hi,

I have a a routine that is frequently called. It simply iterates over a
list of dates and does some sanity checking. The following pseudo code
summarises it.

void check()
{
const Date someDate = 1/1/2005;

for (each item)
{
process(item);
}
}

The above routine is called quite frequently.
My question relates to the construction of the Date object above. It's
constructor doesn't incur any great overhead however I'm curious to
know whether I should make it static. By doing that I'll obviously
call its constructor just once and will therefore save some time at
that point, but I'm wondering about the runtime overhead of using a
static? Is there a downside? This isn't a big issue at all, I'm just
curious to know whether it would be better declared as static or
constructed each time I invoke the routine.

If it's a constant, why keep constructing it? Use a static.

Ian

[benben]

In addtion to my previous post:

The sole reason of having a constructor is to hold a validity of a certain
concept. In this case, a valid date shall be established by Date's
constructor, while other member functions help maintain the validity and
defence against unreasonable use. Not doing it results in ineffective design
so that the a date object must be checked from time to time. Keep it simple:

class Date
{
private:
check() throw(Bad_date);

public:
Date();

Date(Year yy, Month mm, Day dd)
{
//...
check();
}

Date(const Date& dt)
{
// don't have to check
// dt is always valid
}

Date& operator = (const Date& dt)
{
// don't have to check
// dt is always valid
}
};

[Grahamo]

thanks for the replies, I think I should clarify. My question relates
to the *overhead* of having the Date object declared static as opposed
to instantiating one on the stack each time my check() routine is
called.

i.e. should I define;

void check()
{
const Date someDate = 1/1/2005;
// do processing

}

or should I define

void check()
{
static const Date someDate = 1/1/2005;
// do processing

}

In the latter case the Date object constructor is called only once
however I'm interested in understanding the overhead of doing this.
i.e. what overhead am I incurring by declaring it static. The stack
size will increase as the object is left lying around but apart from
that I don't see any other issues. At the same time I feel that using
this approach is not reccommended. Perhaps I'm wrong.

I'm interested in opinions relating to which approach is better?
Graham

[Grahamo]

thanks for the replies, I think I should clarify. My question relates
to the *overhead* of having the Date object declared static as opposed
to instantiating one on the stack each time my check() routine is
called.

i.e. should I define;

void check()
{
const Date someDate = 1/1/2005;
// do processing

}

or should I define

void check()
{
static const Date someDate = 1/1/2005;
// do processing

}

In the latter case the Date object constructor is called only once
however I'm interested in understanding the overhead of doing this.
i.e. what overhead am I incurring by declaring it static. The stack
size will increase as the object is left lying around but apart from
that I don't see any other issues. At the same time I feel that using
this approach is not reccommended. Perhaps I'm wrong.

I'm interested in opinions relating to which approach is better?
Graham

[ravinderthakur]

well that depends on what you are doing in

//do processing.

if you are doing a lot of stuff there as can be inferred from ur first
post, then i doubt that
any substantail savings can be made,

however if this code doses only a bit of processing and most of time is
spent in
calling constructor and destructor of the object , then this can
definatly be made static and you can do away with calling the
constructor and destructor every time you enter this fucntion.

thanks
rt

[Ian]

Gr*****@nospam.com wrote:

In the latter case the Date object constructor is called only once
however I'm interested in understanding the overhead of doing this.
i.e. what overhead am I incurring by declaring it static. The stack
size will increase as the object is left lying around but apart from
that I don't see any other issues. At the same time I feel that using
this approach is not reccommended. Perhaps I'm wrong.

The stack size will most likely decrease, it makes non sense to have
static objects on the stack.

It is likely to end up somewhere else, exactly where depends on the
implementation.

There is no net overhead, the object has to exist somewhere (assuming it
isn't optimised away).

Ian

[msalters]

Gr*****@nospam.com schreef:

thanks for the replies, I think I should clarify. My question relates
to the *overhead* of having the Date object declared static as opposed
to instantiating one on the stack each time my check() routine is
called. .... In the latter case the Date object constructor is called only once
however I'm interested in understanding the overhead of doing this.
i.e. what overhead am I incurring by declaring it static. The stack
size will increase as the object is left lying around

(disclaimer: C++ implementations may differ)
Static variables usually aren't allocated on the stack. This would be
a problem, as the stack memory is released when returning from a
function. The solution is to allocate memory from some global pool,
and call a ctor on that memory once the static is constructed. Of
course, an optimizer might detect that the result is predictable and
optimize it away.
But the basic tradeoff is there: speed vs memory.

HTH,
Michiel Salters

[Grahamo]

thanks for those replies and clarifications. I've gone with static as
there isn't a lot of processing being done.

cheers, G