Question about variable scope and processor load

Hi all,
I have a question about how variable scope works. As I understand it, if you define a variable in the setup() loop, it's only accessible within setup(). Ditto for the loop() functions, or interrupt routines.

Say that I put a variable declaration within loop(), like so:

void loop() {
int myvariable;

//some other code here...
.
.
.

} //end loop()

does that mean that the processor will spend time finding a spot in memory for that variable every time it rolls through loop(), or is it smart enough to skip that instruction after the first time?

What if I define and initialize the variable, e.g.

void loop() {
int myvariable = 24; //now I have set an initial value

//some other code here...
.
.
.

} //end loop()

Interesting questions.

For your first case (uninitialized local variable), yes, the processor will "spend time" making room for your variable, but it's not very much time at all. It doesn't have to 'find' a spot...it knows exactly where to put it (on the stack, if that helps at all).

If you define and initialize the variable it does the same thing, but requires an extra step to set the variable to its initial value. A little extra time compared to the previous case, but still not very much time at all.

Thanks for the info. Do you know a method or reference for evaluating processor load on the Arduino?

I keep finding myself in situations (like receiving serial at 250Kbps, or real-time audio generation) where I would like to squeeze just a little more performance out of the processor, and so it would be nice to know exactly how many clock cycles I'm saving by going to direct port manipulation vs. digitalWrite(), for example.

The most instructive and accurate way to do it is to study the assembly-language output of your code, compute the number of clock cycles taken up by each approach, then compare.

That's a lot of work. An approach I often take is to set a digital I/O pin high when some piece of work starts, then set it low when it ends, and use a logic analyzer or oscilloscope to measure the width of this I/O pin pulse. This tells you how long your code takes to execute.

The coarsest but simplest way when you have a repetitive "long" task is to increment a counter when the processor is idle, in the main loop. Then, every second or so print out its value. Comparing how many "counts per second" you get with one approach vs. another gives you a relative measure of efficiency.

Uf. I was afraid the answer had something to do with assembly code. But banging a pin and looking at the pulse length on an o-scope is a great work-around, thanks for the tip.

Oh, I was reading the reference and I found the static keyword. static will set the variable the first time the function calls it, but leave it alone after that, while still setting it as a local variable so that other functions can't change it.

I need to look at what happens at compile time to see what the effect on processor load is though...