Static vs Dynamic Variables - Speed Difference

[Guest]

I have a function which is called from a loop many times. In that function,
I use three variables as counters and for other purposes. I can either use
DIM for declaring the variables or Static. Would the performance be better
using Static versus Dynamic. I would think it would be quicker with STATIC
declarations since the variables would only have to be created once. Can
anyone confirm this. Thanks.

 

[Scott M.]

It's not a matter of performance, it's a matter of whether you need the
values of those variables persisted between calls to the function in
question. If you do - use static. If you don't - use Dim.

 

[Jeff Stewart]

But strictly speaking, won't static produce less memory allocation code than
repeated calls to dim?

 

[Marina]

I wouldn't worry about your program's performance suffering because of this
choice. This will not be the bottleneck.

You should use what makes sense in the function. If the variable's value
does not need to be saved between function calls, then just dim the
variables.

 

[Imran Koradia]

Scott's argument is absolutely right - use static variables when you need
them otherwise stick to dimming the variables.

In addition, the CLR itself does not support static variables. This is
achieved by the VB compiler instead and this does incur a slight overhead -
not so much that you shouldn't use them even when you absolutely need to.
Here's a blog post that should explain why this overhead with static
variables:
http://weblogs.asp.net/psteele/articles/7717.aspx

The idea is that for normal programming, simply use local variables. Use
static variables only when you need them - when it indeed does make sense to
use them.


hope that helps..
Imran.

 

[Larry Serflaten]

I have a function which is called from a loop many times. In that function,
I use three variables as counters and for other purposes. I can either use
DIM for declaring the variables or Static. Would the performance be better
using Static versus Dynamic. I would think it would be quicker with STATIC
declarations since the variables would only have to be created once. Can
anyone confirm this. Thanks.

Don't ry to second guess the compiler. Create and use variables as you need them
(least scope) and let the compiler decide how to optimize their use.

LFS

 

[Herfried K. Wagner [MVP]]

But strictly speaking, won't static produce less memory
allocation code than repeated calls to dim?

Why? If only one instance of your method is running, there will only be one
instance of the local variable.

 

[Jeff Stewart]

In the dim scenario:
1) When the method is called, code must be executed to allocate storage
for the dim'd variable, which has local scope.
2) Leaving the method's scope can (should, I hope!) cause that dim'd
variable to be reclaimed. Subsequent calls to the method repeat step 1, and
subsequent returns cause step 2 to be repeated.

In the static scenario:
1) The variable storage is allocated when the class is instantiated (or
the first time the method is called, depending on the compiler).
2) Each time the method is called (with the possible exception of the
first time, depending on the compiler), the variable's storage is -not-
reallocated -- memory allocation code is not necessary; it is the same as it
was before. So step 1 above is not performed. Similarly, when leaving the
method (so long as the class instance remains active), storage is not
reclaimed, so step 2 above is not performed.

It's probably a moot point, but it still seems to me like less instructions
are executed in the latter scenario than the former. I'm sure that the
compilers out there have clever tricks for this kind of stuff, but since
most of my work is done in firmware, I worry about this stuff.

 

[Jay B. Harlow [MVP - Outlook]]

Jeff,
No Static will cause 2 or more class variables to be created, while (local)
Dim will cause a single variable stack based variable to be created.

If the method is called very rarely, you are "wasting" class variable space,
and if the variable is a Reference Type, you may also be "wasting" Heap
space.

For example look at the following class with ILDASM.EXE:

Public Class DynamicClass

Public Sub DoSomething()
Static SomeStaticValue As Integer = 100
Dim SomeLocalValue As Integer = 100
End Sub

End Class

You should see that SomeStaticValue caused two class level variables to be
created.

The first "$STATIC$DoSomething$2001$SomeStaticValue" is the value of the
Static variable.
The second "$STATIC$DoSomething$2001$SomeStaticValue$Init" is a special
class that indicates if the static value has been initialized yet or not.

You should also see that VB.NET added code to the constructor to initialize
the $STATIC$DoSomething$2001$SomeStaticValue$Init variable, plus it added a
whole lot of extra code to our method to support the Static Variable...

I totally agree & follow Scott M's comments when deciding to use Static over
Dim!

Hope this helps
Jay

 

[Michael D. Ober]

The same number of instructions are created in each case. When entering a
function or sub procedure, the instruction SUB ESP, n is added to the start
of the function. "n" is computed at compile time to hold all (DIM)
variables needed by that function. Note that this instruction must also be
executed even if there are no variables because the stack frame pointer (BP)
must also be saved on the stack, so at mininum n must be 2 as BP is 2 bytes
long. Referencing variables on the stack frame or in global data storage
takes the same number of clock cycles, assuming the memory page for both is
already in memory.

Mike Ober.

 

[Scott M.]

Yes, but the values are held in memory potentially longer than using Dim.

 

[Scott M.]

Not really Herifried. There may be only one instance that is accessible,
but there will most certainly be instances left on the stack/heap that are
no longer being referenced and waiting to be collected.

 

[Jeff Stewart]

A couple of questions, then:
1) Why is a -class- necessary to determine whether a static has been
initialized or not? It seems a little heavy.
2) What is the extra code needed to support the variable? I'd have thought
the linker would simply have references to that static variable use a
different memory location.

--
Jeff S.

Jeff,
No Static will cause 2 or more class variables to be created, while
(local) Dim will cause a single variable stack based variable to be
created.

If the method is called very rarely, you are "wasting" class variable
space, and if the variable is a Reference Type, you may also be "wasting"
Heap space.

For example look at the following class with ILDASM.EXE:

Public Class DynamicClass

Public Sub DoSomething()
Static SomeStaticValue As Integer = 100
Dim SomeLocalValue As Integer = 100
End Sub

End Class

You should see that SomeStaticValue caused two class level variables to be
created.

The first "$STATIC$DoSomething$2001$SomeStaticValue" is the value of the
Static variable.
The second "$STATIC$DoSomething$2001$SomeStaticValue$Init" is a special
class that indicates if the static value has been initialized yet or not.

You should also see that VB.NET added code to the constructor to
initialize the $STATIC$DoSomething$2001$SomeStaticValue$Init variable,
plus it added a whole lot of extra code to our method to support the
Static Variable...

I totally agree & follow Scott M's comments when deciding to use Static
over Dim!

Hope this helps
Jay

 

[Guest]

Based on the lively discussion, I guess I should be using DIm instead of
Static unless I really need the Static part. Thanks all for your discussion.
I think we learned a lot from the Experts!

 

[Herfried K. Wagner [MVP]]

Not really Herifried. There may be only one instance that is accessible,
but there will most certainly be instances left on the stack/heap that are
no longer being referenced and waiting to be collected.

That's true. But the GC should take care that this doesn't have a negative
impact on the application/system.

 

[Scott M.]

Sure it can. By adding more objects to the stack/heap, you increase the
change that the GC will collect sooner than normal. The sheer act of
collection takes processor cycles away from everything else and therefore it
is less efficient.

I know what you are saying, but if we are to get technical and talk about
performance, then it is correct to say that the less things you put into
memory in the first place, the better.

 

[Herfried K. Wagner [MVP]]

Scott --

Sure it can. By adding more objects to the stack/heap,
you increase the change that the GC will collect sooner than
normal. The sheer act of collection takes processor cycles away
from everything else and therefore it is less efficient.

You are absolutely right. I missed the "speed difference" in the subject
when writing my reply and thought about memory usage ;-(.

 

[Jay B. Harlow [MVP - Outlook]]

Scott,
Variables are never left on the stack! (instead the space where the
variables were is reused each time a routine is called).

You are partially correct in that a Reference type that a stack variable
refers to may be still on the heap when the routine is done, however the
variable itself is long immediately at the end of the current routine.

The original poster stated counters, which strongly suggests integers, which
are value types, which means that the heap is not involved.

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Scott,
You do realize that stack variables themselves are never garbage collected.

That only objects referenced by reference type stack variables are garbage
collected.

In other words the GC only manages the heap. The Stack is a stack (LIFO) the
runtime pushes stack frames (a handful of variables) onto the stack at the
start of a routine, and pops (discards) the stack frame at the end of the
routine. Which means that value type variables on the stack are handled
immediately & very efficiently!

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Jeff,
The extra code is used to determine if the variable has been initialized or
not, the variable is only initialized on the first call into the routine
(not in the constructor).

MS needed/wanted to preserve the semantics that VB6 had for Static
variables, so this extra stuff is used to help ensure those semantics. MS
also needed to ensure thread safety for the Static variable.

Which also means if the routine is never called, then the variable is never
initialized, which can be a good thing, especially if the act of
initializing the variable causes side effects...

Which means that uses Static, instead of coding it yourself (as C# would
need to do) has a number of benefits, which include but are not limited to:

- The Static variable is 100% encapsulated to that routine (other methods of
the class will not see the variable).
- The initialization of the Static variable is implicitly thread safe. Note
its use may not be...

Hope this helps
Jay