Static vs Dynamic Variables - Speed Difference

[Dennis]

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.
--
Dennis in Houston

[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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[Jeff Stewart]

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

--
Jeff S.
"Scott M." <s-***@nospam.nospam> wrote in message
news:eh**************@TK2MSFTNGP15.phx.gbl...

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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[Larry Serflaten]

"Dennis" <De****@discussions.microsoft.com> wrote

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

[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.

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[Herfried K. Wagner [MVP]]

"Jeff Stewart" <ja*@micronovatech.com> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[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

"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099683393.4UNPUC0WXjL+DJxWnHS5yg@teranews...

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

--
Jeff S.
"Scott M." <s-***@nospam.nospam> wrote in message
news:eh**************@TK2MSFTNGP15.phx.gbl...

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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[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.

"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099688650.NnV0SgOw/OuZ4gQFdZ+cag@teranews...

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. :)

--
Jeff S.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

"Jeff Stewart" <ja*@micronovatech.com> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Scott M.]

Yes, but the values are held in memory potentially longer than using Dim.
"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099683393.4UNPUC0WXjL+DJxWnHS5yg@teranews...

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

--
Jeff S.
"Scott M." <s-***@nospam.nospam> wrote in message
news:eh**************@TK2MSFTNGP15.phx.gbl...

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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...

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.
--
Dennis in Houston

[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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

"Jeff Stewart" <ja*@micronovatech.com> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Dennis]

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!

"Dennis" wrote:

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.
--
Dennis in Houston

[Herfried K. Wagner [MVP]]

"Scott M." <s-***@nospam.nospam> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[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]" <hi***************@gmx.at> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

"Scott M." <s-***@nospam.nospam> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

Scott --

"Scott M." <s-***@nospam.nospam> schrieb:

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 ;-(.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[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


"Scott M." <s-***@nospam.nospam> wrote in message
news:Ok**************@TK2MSFTNGP14.phx.gbl...

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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

"Jeff Stewart" <ja*@micronovatech.com> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[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

"Scott M." <s-***@nospam.nospam> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...

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]" <hi***************@gmx.at> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

"Scott M." <s-***@nospam.nospam> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[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

"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099696684.Bx6w/JfwPMb47qkylGNhKA@teranews...

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.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ur**************@TK2MSFTNGP15.phx.gbl...

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

"Jeff Stewart" <ja*@micronovatech.com> wrote in message
news:1099683393.4UNPUC0WXjL+DJxWnHS5yg@teranews...

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

--
Jeff S.
"Scott M." <s-***@nospam.nospam> wrote in message
news:eh**************@TK2MSFTNGP15.phx.gbl...
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.
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:9D**********************************@microsof t.com...
>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.
> --
> Dennis in Houston

[Ravichandran J.V.]

But then you must consider that dynamic variables will allocated memory
on the heap and hence may be faster. It is very ambiguous because it
also depends on whether the variables will be Value or Reference
variables.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Scott M.]

Thanks Jay. I did realize that but what I was trying to say was that the
more things we place into memory (any memory) will mean more things have to
come out of memory later. And that the sheer act of doing that (whether it
be the GC cleaning the heap or the stack frame being discarded) uses
processor clock cycles.

Thanks again.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ey**************@TK2MSFTNGP15.phx.gbl...

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

"Scott M." <s-***@nospam.nospam> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...

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]" <hi***************@gmx.at> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...

"Scott M." <s-***@nospam.nospam> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Scott M.]

See my reply to your reply to me above. But isn't it also possible that an
Integer can, in fact, be stored on the heap if it is part of a larger
reference type object?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...

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


"Scott M." <s-***@nospam.nospam> wrote in message
news:Ok**************@TK2MSFTNGP14.phx.gbl...

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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

"Jeff Stewart" <ja*@micronovatech.com> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Scott,
Of course, I never said they weren't.

Jay

"Scott M." <s-***@nospam.nospam> wrote in message
news:ul**************@TK2MSFTNGP10.phx.gbl...

See my reply to your reply to me above. But isn't it also possible that
an Integer can, in fact, be stored on the heap if it is part of a larger
reference type object?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...

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


"Scott M." <s-***@nospam.nospam> wrote in message
news:Ok**************@TK2MSFTNGP14.phx.gbl...

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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...
"Jeff Stewart" <ja*@micronovatech.com> schrieb:
> 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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Scott,
As Michael suggests, discarding the stack frame is little (very little) more
then a subtract statement. The number of processor clock cycles is going to
be so insignificant that for the far majority of developers it doesn't
exist.

Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been identified &
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Thanks Jay. I did realize that but what I was trying to say was that the
more things we place into memory (any memory) will mean more things have
to come out of memory later. And that the sheer act of doing that
(whether it be the GC cleaning the heap or the stack frame being
discarded) uses processor clock cycles.

Thanks again.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ey**************@TK2MSFTNGP15.phx.gbl...

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

"Scott M." <s-***@nospam.nospam> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...

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]" <hi***************@gmx.at> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...
"Scott M." <s-***@nospam.nospam> schrieb:
> 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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Scott M.]

I don't disagree Jay. But the OP was about performance and my answer(s)
were strictly based on that in the most literal of ways.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Scott,
As Michael suggests, discarding the stack frame is little (very little)
more then a subtract statement. The number of processor clock cycles is
going to be so insignificant that for the far majority of developers it
doesn't exist.

Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been identified
&
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Thanks Jay. I did realize that but what I was trying to say was that the
more things we place into memory (any memory) will mean more things have
to come out of memory later. And that the sheer act of doing that
(whether it be the GC cleaning the heap or the stack frame being
discarded) uses processor clock cycles.

Thanks again.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ey**************@TK2MSFTNGP15.phx.gbl...

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

"Scott M." <s-***@nospam.nospam> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...
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]" <hi***************@gmx.at> wrote in message
news:Oo**************@TK2MSFTNGP10.phx.gbl...
> "Scott M." <s-***@nospam.nospam> schrieb:
>> 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.
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>
>
>

[Scott M.]

And, that was why when the OP mentioned "integer", I indicated that the heap
can still be a factor.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Oe**************@TK2MSFTNGP10.phx.gbl...

Scott,
Of course, I never said they weren't.

Jay

"Scott M." <s-***@nospam.nospam> wrote in message
news:ul**************@TK2MSFTNGP10.phx.gbl...

See my reply to your reply to me above. But isn't it also possible that
an Integer can, in fact, be stored on the heap if it is part of a larger
reference type object?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:u1**************@TK2MSFTNGP15.phx.gbl...

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


"Scott M." <s-***@nospam.nospam> wrote in message
news:Ok**************@TK2MSFTNGP14.phx.gbl...
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.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...
> "Jeff Stewart" <ja*@micronovatech.com> schrieb:
>> 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.
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>
>
>

[Jay B. Harlow [MVP - Outlook]]

Scott,
See other thread.

Jay

"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

And, that was why when the OP mentioned "integer", I indicated that the
heap can still be a factor.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:Oe**************@TK2MSFTNGP10.phx.gbl...

Scott,
Of course, I never said they weren't.

Jay

"Scott M." <s-***@nospam.nospam> wrote in message
news:ul**************@TK2MSFTNGP10.phx.gbl...

See my reply to your reply to me above. But isn't it also possible that
an Integer can, in fact, be stored on the heap if it is part of a larger
reference type object?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:u1**************@TK2MSFTNGP15.phx.gbl...
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


"Scott M." <s-***@nospam.nospam> wrote in message
news:Ok**************@TK2MSFTNGP14.phx.gbl...
> 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.
>
>
> "Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
> news:O3**************@TK2MSFTNGP09.phx.gbl...
>> "Jeff Stewart" <ja*@micronovatech.com> schrieb:
>>> 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.
>>
>> --
>> Herfried K. Wagner [MVP]
>> <URL:http://dotnet.mvps.org/>
>>
>>
>
>

[Jay B. Harlow [MVP - Outlook]]

Scott,
What I am suggesting is that using a Static may actually hurt performance
not help performance, largely based on the amount of extra IL generated. The
fact the Static Integer is part of containing object or on the heap seems
immaterial to me. As in either case the counter itself is not subject to GC.

Without actually profiling the two methods, neither of use can really claim
which one performs better. Plus I'm sure either of us could contrive
benchmarks that would suggest that one performed better then the other. To
accurately profile the methods you would need to run the code in the
situation that the original OP has.

I find it odd that you appear to be arguing with me, when you initially
stated that performance doesn't matter, I hope you will understand that I am
dropping out of this discussion...

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:uQ**************@tk2msftngp13.phx.gbl...

I don't disagree Jay. But the OP was about performance and my answer(s)
were strictly based on that in the most literal of ways.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Scott,
As Michael suggests, discarding the stack frame is little (very little)
more then a subtract statement. The number of processor clock cycles is
going to be so insignificant that for the far majority of developers it
doesn't exist.

Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been
identified &
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Thanks Jay. I did realize that but what I was trying to say was that
the more things we place into memory (any memory) will mean more things
have to come out of memory later. And that the sheer act of doing that
(whether it be the GC cleaning the heap or the stack frame being
discarded) uses processor clock cycles.

Thanks again.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:ey**************@TK2MSFTNGP15.phx.gbl...
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

"Scott M." <s-***@nospam.nospam> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...
> 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]" <hi***************@gmx.at> wrote in message
> news:Oo**************@TK2MSFTNGP10.phx.gbl...
>> "Scott M." <s-***@nospam.nospam> schrieb:
>>> 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.
>>
>> --
>> Herfried K. Wagner [MVP]
>> <URL:http://dotnet.mvps.org/>
>>
>>
>
>

[Cor Ligthert]

Herfried,

I found the answers from Scott until he became involved in an academical
discussion very good. Are you asking this as an accademical question for
yourself or to help the OP. I think that makes a big differenc.

I do not like static values, however there where it is for reading better
than a globaly placed value I will use them.

To the OP my answer is why botter about this, keep eye on the structure of
your code. When you need a static variable only in one method, use a static
in the otherway set it global (what does not mean for me directly in the top
of the program).

The performance done with this is about thousands of nanoseconds.

Just my thought,

Cor

"Herfried K. Wagner [MVP]"

"Jeff Stewart" <ja*@micronovatech.com> schrieb:

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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Scott M.]

I am very confused Jay. I haven't argued or disputed anything you've said.
I didn't say you were wrong and I didn't say that Dim or Static was the
better choice. I was simply trying to point out pro's con's of each
scenario. I asked you a question or two to clarify items for me and you
did.

I think you may want to go back and read the thread again. Sorry if you got
the wrong impression.

Thank you.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:u$**************@TK2MSFTNGP09.phx.gbl...

Scott,
What I am suggesting is that using a Static may actually hurt performance
not help performance, largely based on the amount of extra IL generated.
The fact the Static Integer is part of containing object or on the heap
seems immaterial to me. As in either case the counter itself is not
subject to GC.

Without actually profiling the two methods, neither of use can really
claim which one performs better. Plus I'm sure either of us could contrive
benchmarks that would suggest that one performed better then the other. To
accurately profile the methods you would need to run the code in the
situation that the original OP has.

I find it odd that you appear to be arguing with me, when you initially
stated that performance doesn't matter, I hope you will understand that I
am dropping out of this discussion...

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:uQ**************@tk2msftngp13.phx.gbl...

I don't disagree Jay. But the OP was about performance and my answer(s)
were strictly based on that in the most literal of ways.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

Scott,
As Michael suggests, discarding the stack frame is little (very little)
more then a subtract statement. The number of processor clock cycles is
going to be so insignificant that for the far majority of developers it
doesn't exist.

Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been
identified &
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at
http://martinfowler.com/ieeeSoftware...timization.pdf

Info on the CLR Profiler:
http://msdn.microsoft.com/library/de...nethowto13.asp

http://msdn.microsoft.com/library/de...anagedapps.asp

Hope this helps
Jay
"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
Thanks Jay. I did realize that but what I was trying to say was that
the more things we place into memory (any memory) will mean more things
have to come out of memory later. And that the sheer act of doing that
(whether it be the GC cleaning the heap or the stack frame being
discarded) uses processor clock cycles.

Thanks again.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:ey**************@TK2MSFTNGP15.phx.gbl...
> 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
>
> "Scott M." <s-***@nospam.nospam> wrote in message
> news:uF**************@TK2MSFTNGP10.phx.gbl...
>> 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]" <hi***************@gmx.at> wrote in
>> message news:Oo**************@TK2MSFTNGP10.phx.gbl...
>>> "Scott M." <s-***@nospam.nospam> schrieb:
>>>> 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.
>>>
>>> --
>>> Herfried K. Wagner [MVP]
>>> <URL:http://dotnet.mvps.org/>
>>>
>>>
>>
>>
>
>