Static vs Non-Static Function Performance

[Steve - DND]

We're currently doing some tests to determine the performance of static vs
non-static functions, and we're coming up with some odd(in our opinion)
results. We used a very simple setup. One class had a static function, and
the one class had a non-static function. Both of these functions did the
exact same thing.

The test function:
public void Test(){
decimal y = 2;
decimal x = 3;
decimal d = 0;

for(decimal z = 0; z < 1000000;z++){
if(z % 2 == 0){
d = y*d;
} else {
d = x*d;
}
}
}

The test running code:
for (int i = 0; i < 1000; i++) {
StaticTest.Test();
}

for (int i = 0; i < 1000; i++) {
NonStaticTest nst = new NonStaticTest();
nst.Test();
}

To our suprise the non-static approach ran in 15 minutes, and the static
approach ran in 17 minutes. We had figured that due to the need to
instantiate a new object with each call for the non-static approach, that
this way would take longer. We also tried running the non-static approach
first, and the static approach second, the results were the same. We ran
these tests 3 times each to make sure that we got a nice average.

Did we somehow bias the test towards the non-static approach? How is it that
with an object instantion going on, the non-static approach is able to run
in 2 minutes less time. This is of course a substantially large margin, and
could have some definite performance implications for those building
performance oriented code.

Thanks,
Steve

[Michael Culley]

Hi Steve,

There could be some optimisations going on that are giving false results.

--
Michael Culley
"Steve - DND" <[e-mail]> wrote in message news:#w**************@tk2msftngp13.phx.gbl...

We're currently doing some tests to determine the performance of static vs
non-static functions, and we're coming up with some odd(in our opinion)
results. We used a very simple setup. One class had a static function, and
the one class had a non-static function. Both of these functions did the
exact same thing.

The test function:
public void Test(){
decimal y = 2;
decimal x = 3;
decimal d = 0;

for(decimal z = 0; z < 1000000;z++){
if(z % 2 == 0){
d = y*d;
} else {
d = x*d;
}
}
}

The test running code:
for (int i = 0; i < 1000; i++) {
StaticTest.Test();
}

for (int i = 0; i < 1000; i++) {
NonStaticTest nst = new NonStaticTest();
nst.Test();
}

To our suprise the non-static approach ran in 15 minutes, and the static
approach ran in 17 minutes. We had figured that due to the need to
instantiate a new object with each call for the non-static approach, that
this way would take longer. We also tried running the non-static approach
first, and the static approach second, the results were the same. We ran
these tests 3 times each to make sure that we got a nice average.

Did we somehow bias the test towards the non-static approach? How is it that
with an object instantion going on, the non-static approach is able to run
in 2 minutes less time. This is of course a substantially large margin, and
could have some definite performance implications for those building
performance oriented code.

Thanks,
Steve

[Steve - DND]

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...

Hi Steve,

There could be some optimisations going on that are giving false results.

--
Michael Culley

Any idea what these enhancements could be? They should be doing the same
thing, should they not?

Steve

[Michael Culley]

"Steve - DND" <[e-mail]> wrote in message news:#q**************@TK2MSFTNGP11.phx.gbl...

Any idea what these enhancements could be? They should be doing the same
thing, should they not?
I can see several posibilities. The compiler might work out that nothing is returned from the function so optimise out some of the
code in the function. It could treat the function as static because it doesn't use an module level variables and it might not even
bother creating the object at all. All of these are just guesses though.

--
Michael Culley
"Steve - DND" <[e-mail]> wrote in message news:#q**************@TK2MSFTNGP11.phx.gbl... "Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...

Hi Steve,

There could be some optimisations going on that are giving false results.

--
Michael Culley

Any idea what these enhancements could be? They should be doing the same
thing, should they not?

Steve

[codymanix]

Thats because static methods are using locks to be Thread-safe. The always
do internally a Monitor.Enter() and Monitor.exit() to ensure Thread-safety.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Steve - DND]

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:un**************@TK2MSFTNGP09.phx.gbl...

"Steve - DND" <[e-mail]> wrote in message news:#q**************@TK2MSFTNGP11.phx.gbl...

Any idea what these enhancements could be? They should be doing the same
thing, should they not?

I can see several posibilities. The compiler might work out that nothing

is returned from the function so optimise out some of the code in the function. It could treat the function as static because it doesn't use an module level variables and it might not even bother creating the object at all. All of these are just guesses though.

Looks like you were correct. There seemed to be some optimizations going on.
When I changed things up a bit, I got *very* different results(static
running in less than 50% of the time).

Thanks,
Steve

[Telmo Sampaio]

maybe object pooling ?

--
Telmo Sampaio
MCSE (4 and 2k), MCSA, MCSD (6 and .NET), MCDBA, MCT, SPS, STA, SCSE, SAT,
MSF Practitioner, ITIL Certified
te***********@hotmail.com
"Steve - DND" <[e-mail]> wrote in message
news:#q**************@TK2MSFTNGP11.phx.gbl...

"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:O%****************@TK2MSFTNGP10.phx.gbl...

Hi Steve,

There could be some optimisations going on that are giving false results.
--
Michael Culley

Any idea what these enhancements could be? They should be doing the same
thing, should they not?

Steve

[mikeb]

codymanix wrote:

Thats because static methods are using locks to be Thread-safe. The always
do internally a Monitor.Enter() and Monitor.exit() to ensure Thread-safety.

Are you sure? Do you have a pointer to some docs that describe this?

I find it hard to believe that it would do this automatically, since
it's easy enough to place the entire method body in a lock statement
block, and there are many cases where static methods would have no need
to use Monitors to ensure thread safety.

--
mikeb

[Alvin Bruney]

He is right. Take a look at the Il code or google for it.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"mikeb" <ma************@mailnull.com> wrote in message
news:u7**************@TK2MSFTNGP09.phx.gbl...

codymanix wrote:

Thats because static methods are using locks to be Thread-safe. The always do internally a Monitor.Enter() and Monitor.exit() to ensure Thread-safety.

Are you sure? Do you have a pointer to some docs that describe this?

I find it hard to believe that it would do this automatically, since
it's easy enough to place the entire method body in a lock statement
block, and there are many cases where static methods would have no need
to use Monitors to ensure thread safety.

--
mikeb

[Michael Culley]

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:OM**************@tk2msftngp13.phx.gbl...

He is right. Take a look at the Il code or google for it.

So static functions should be avoided where optimum speed is needed?

--
Michael Culley

[Steve - DND]

> > Are you sure? Do you have a pointer to some docs that describe this?

I find it hard to believe that it would do this automatically, since
it's easy enough to place the entire method body in a lock statement
block, and there are many cases where static methods would have no need
to use Monitors to ensure thread safety.

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:OM**************@tk2msftngp13.phx.gbl... He is right. Take a look at the Il code or google for it.

I took a look at the IL code and disassembled code for both a static and
non-static function, and they're identical. Can you provide an example where
Monitor.Enter() or Monitor.Exit() is used automatically?

public class StaticTest {
public static void Test() {
decimal d = 2;
}
}

public class NonStaticTest {
public void Test() {
decimal d = 2;
}
}

***** Disassembly *****
..method public hidebysig instance void Test() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] valuetype [mscorlib]System.Decimal d)
IL_0000: ldc.i4.2
IL_0001: newobj instance void [mscorlib]System.Decimal::.ctor(int32)
IL_0006: stloc.0
IL_0007: ret
} // end of method NonStaticTest::Test

..method public hidebysig static void Test() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] valuetype [mscorlib]System.Decimal d)
IL_0000: ldc.i4.2
IL_0001: newobj instance void [mscorlib]System.Decimal::.ctor(int32)
IL_0006: stloc.0
IL_0007: ret
} // end of method StaticTest::Test

Steve

[Alvin Bruney]

I think i am wrong on this one. The dissambly is painfully obvious that I
don't know what I am talking about :-)

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Steve - DND" <steve!@!digitalnothing.com> wrote in message
news:Od**************@TK2MSFTNGP12.phx.gbl...

Are you sure? Do you have a pointer to some docs that describe this?

I find it hard to believe that it would do this automatically, since
it's easy enough to place the entire method body in a lock statement
block, and there are many cases where static methods would have no need to use Monitors to ensure thread safety.

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in
message news:OM**************@tk2msftngp13.phx.gbl...

He is right. Take a look at the Il code or google for it.

I took a look at the IL code and disassembled code for both a static and
non-static function, and they're identical. Can you provide an example

where Monitor.Enter() or Monitor.Exit() is used automatically?

public class StaticTest {
public static void Test() {
decimal d = 2;
}
}

public class NonStaticTest {
public void Test() {
decimal d = 2;
}
}

***** Disassembly *****
.method public hidebysig instance void Test() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] valuetype [mscorlib]System.Decimal d)
IL_0000: ldc.i4.2
IL_0001: newobj instance void [mscorlib]System.Decimal::.ctor(int32) IL_0006: stloc.0
IL_0007: ret
} // end of method NonStaticTest::Test

.method public hidebysig static void Test() cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init ([0] valuetype [mscorlib]System.Decimal d)
IL_0000: ldc.i4.2
IL_0001: newobj instance void [mscorlib]System.Decimal::.ctor(int32) IL_0006: stloc.0
IL_0007: ret
} // end of method StaticTest::Test

Steve

[mikeb]

"Alvin Bruney" <vapordan_spam_me_not@hotmail_no_spamhotmail.com > wrote in message news:<OM**************@tk2msftngp13.phx.gbl>...

He is right. Take a look at the Il code or google for it.

Like Steve at DND, I did try this, and found no evidence of a simple
static method being automatically locked.


-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"mikeb" <ma************@mailnull.com> wrote in message
news:u7**************@TK2MSFTNGP09.phx.gbl...

codymanix wrote:

Thats because static methods are using locks to be Thread-safe. The always do internally a Monitor.Enter() and Monitor.exit() to ensure Thread-safety.

Are you sure? Do you have a pointer to some docs that describe this?

I find it hard to believe that it would do this automatically, since
it's easy enough to place the entire method body in a lock statement
block, and there are many cases where static methods would have no need
to use Monitors to ensure thread safety.

--
mikeb

--
mikeb

[Jon Skeet [C# MVP]]

codymanix <do*********************@gmx.de> wrote:

Thats because static methods are using locks to be Thread-safe. The always
do internally a Monitor.Enter() and Monitor.exit() to ensure Thread-safety.

They definitely, definitely don't.

Here's an example program which shows two threads being in the same
method at the same time:

using System;
using System.Threading;

public class Test
{
static void Main()
{
Thread t1 = new Thread (new ThreadStart(Count));
Thread t2 = new Thread (new ThreadStart(Count));

t1.Name = "First thread";
t2.Name = "Second thread";

t1.Start();
t2.Start();
}

static void Count()
{
for (int i=0; i < 10; i++)
{
Console.WriteLine ("{0} {1}", i,
Thread.CurrentThread.Name);
Thread.Sleep (500);
}
}
}

If you put a lock in yourself, eg lock (typeof(Test)) round the body of
Count, you get radically different results (i.e. one thread does the
whole count, then the second one does).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Stu Smith]

Does anyone know where this urban myth about static methods got started?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

codymanix <do*********************@gmx.de> wrote:

Thats because static methods are using locks to be Thread-safe. The always do internally a Monitor.Enter() and Monitor.exit() to ensure

Thread-safety.
They definitely, definitely don't.

Here's an example program which shows two threads being in the same
method at the same time:

using System;
using System.Threading;

public class Test
{
static void Main()
{
Thread t1 = new Thread (new ThreadStart(Count));
Thread t2 = new Thread (new ThreadStart(Count));

t1.Name = "First thread";
t2.Name = "Second thread";

t1.Start();
t2.Start();
}

static void Count()
{
for (int i=0; i < 10; i++)
{
Console.WriteLine ("{0} {1}", i,
Thread.CurrentThread.Name);
Thread.Sleep (500);
}
}
}

If you put a lock in yourself, eg lock (typeof(Test)) round the body of
Count, you get radically different results (i.e. one thread does the
whole count, then the second one does).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Alvin Bruney]

I don't know but it is out there. he he

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"Stu Smith" <st*****@remove.digita.com> wrote in message
news:u3**************@TK2MSFTNGP09.phx.gbl...

Does anyone know where this urban myth about static methods got started?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

codymanix <do*********************@gmx.de> wrote:

Thats because static methods are using locks to be Thread-safe. The always do internally a Monitor.Enter() and Monitor.exit() to ensure

Thread-safety.

They definitely, definitely don't.

Here's an example program which shows two threads being in the same
method at the same time:

using System;
using System.Threading;

public class Test
{
static void Main()
{
Thread t1 = new Thread (new ThreadStart(Count));
Thread t2 = new Thread (new ThreadStart(Count));

t1.Name = "First thread";
t2.Name = "Second thread";

t1.Start();
t2.Start();
}

static void Count()
{
for (int i=0; i < 10; i++)
{
Console.WriteLine ("{0} {1}", i,
Thread.CurrentThread.Name);
Thread.Sleep (500);
}
}
}

If you put a lock in yourself, eg lock (typeof(Test)) round the body of
Count, you get radically different results (i.e. one thread does the
whole count, then the second one does).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[codymanix]

> I took a look at the IL code and disassembled code for both a static and

non-static function, and they're identical. Can you provide an example where Monitor.Enter() or Monitor.Exit() is used automatically?

It is done internally, there is no need that the il explicitly states it.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

[Jon Skeet [C# MVP]]

codymanix <do*********************@gmx.de> wrote:

I took a look at the IL code and disassembled code for both a static and
non-static function, and they're identical. Can you provide an example

where

Monitor.Enter() or Monitor.Exit() is used automatically?

It is done internally, there is no need that the il explicitly states it.

No, it's *not* done internally, as my other post showed. The only
locking which goes on at all is to make sure that the type has been
initialised.

Do you have any evidence at all for your claim?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Michael Culley]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message news:MP************************@msnews.microsoft.c om...

Do you have any evidence at all for your claim?

This could be a myth that has been started because static methods are generally thread safe. It's kinda logical for someone to
conclude that some call is automatically made to make the method thread safe, when in fact it is thread safe (AFAIK, my knowledge of
threads is limited) because it does not use module level variables.

--
Michael Culley

[andrew lowe]

"Stu Smith" <st*****@remove.digita.com> wrote in message
news:u3**************@TK2MSFTNGP09.phx.gbl...

Does anyone know where this urban myth about static methods got started?

I think it stems from the help files:

"Any public static (Shared in Visual Basic) members of this type are safe
for multithreaded operations. Any instance members are not guaranteed to be
thread safe."

I think people read that as "whats that skip.... the static memebers are
thread safe, they must be using some sort of locking mechanism...wicked i'll
pass that along"

andrew

[100]

Hi andrew,
Try to see what most of the static members do:
1. Static properties are readonly
2. Static methods doesn't use any other static variables and almost never
modified their arguments (some of them do like Array.Copy).

In this case you don't have to do any locking to ensure the thread safety.
Anyway if they need to do locking they will, but this is realy unlikely.
B\rgds
100

"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...

"Stu Smith" <st*****@remove.digita.com> wrote in message
news:u3**************@TK2MSFTNGP09.phx.gbl...

Does anyone know where this urban myth about static methods got started?
I think it stems from the help files:

"Any public static (Shared in Visual Basic) members of this type are safe
for multithreaded operations. Any instance members are not guaranteed to

be thread safe."

I think people read that as "whats that skip.... the static memebers are
thread safe, they must be using some sort of locking mechanism...wicked i'll pass that along"

andrew

[andrew lowe]

"100" <10*@100.com> wrote in message
news:Oi**************@TK2MSFTNGP10.phx.gbl...

Hi andrew,
Try to see what most of the static members do:
1. Static properties are readonly
2. Static methods doesn't use any other static variables and almost never
modified their arguments (some of them do like Array.Copy).

In this case you don't have to do any locking to ensure the thread safety.
Anyway if they need to do locking they will, but this is realy unlikely.

Yes i know :) i was trying to illustrate how the myth was being perpetuated

andrew

[Alvin Bruney]

that sounds so familliar. i think that is how i picked it up as well.

--
-----------
Got TidBits?
Get it here: www.networkip.net/tidbits
"andrew lowe" <andrew dot lowe at geac dot com> wrote in message
news:OC**************@tk2msftngp13.phx.gbl...

"Stu Smith" <st*****@remove.digita.com> wrote in message
news:u3**************@TK2MSFTNGP09.phx.gbl...

Does anyone know where this urban myth about static methods got started?
I think it stems from the help files:

"Any public static (Shared in Visual Basic) members of this type are safe
for multithreaded operations. Any instance members are not guaranteed to

be thread safe."

I think people read that as "whats that skip.... the static memebers are
thread safe, they must be using some sort of locking mechanism...wicked i'll pass that along"

andrew