Does Static class affect performance of ASP.NET site

[Raja Chandrasekaran]

Hai folks,

I have a question to get exact answer from you people. My question is

How Static class is differ from instance class and If you use static
class in ASP.NET, ll it affect speed or performance of site...?

Because I am using static class in my Database layer. But one of my
friend told me that "static class ll take more space than instance
class and it ll affect the performance. But if you use Instance class
you can create object and you can destroy that object, so that
performance ll be good." Is that true..? If so how... I want the proper
solution for this.

Thanks in advance
Raja Chandrasekaran

[Marc Gravell]

It depends largely on what resides *on* the class; if this uses stateless
methods (i.e. no static fields are updated), then I don't see any problem
with static - in fact it removes the need to even create any objects (per
call) [although in any useful example this is going to be so trivially
minimal impact].

AVOID using stateful static properties / fields on such classes though;
remember that many threads can be talking to the class, so either you will
get thread-race bugs when multiple clients are connecting, or you'll
wide-spread blocking - essentially yielding only 1 useful thread at a time.

So:
* stateless static should be fine
* stateful instance should be fine
* performance isn't really a factor unless these are mammoth classes, in
which case you have bigger problems

Marc

[Marc Gravell]

> i.e. no static fields are updated
should have read
"no static fields are used"

[Raja Chandrasekaran]

Marc Gravell wrote:

i.e. no static fields are updated

should have read
"no static fields are used"

Thanks for comment.its fine. But If I use Normal class with static
members and functions... what ll be the advantages and disadvantages...
Y I am aasking to increase the performance of my application by all the
ways...

[Marc Gravell]

for this scenario, any static members should be stateless

Your colleagure wouldn't be confusing this with the VB6 world, would they? A
..Net static class does *not* mean that an instance is created and re-used
for multiple callers. Quite the opposite. There /is/ no instance ("there is
no spoon"); the methods are accessed via the type-definition directly. This
means that there is no need to instantiate or GC any instances, which should
theoretically lead to increased performance (I haven't qualified this, as it
would need some digging). However, the difference is going to be so marginal
(compared to everything else happening) that I would opt for whatever keeps
the system simplest.

That being said - there is never any purpose in having non-static stateless
methods (in fact, FxCop used to whinge at me for doing this...).

The real question is: is my usage stateless? Or do I rely on any static
fields / whatever. If your methods are stateless, then go static: you will
save a few lines of code and get some minor performance hits; nothing to get
excited over, though. If your methods are *not* stateless, then go instance.

Marc

[Nicholas Paldino [.NET/C# MVP]]

Marc,

I disagree with the statement that static members should be stateless.
It is very possible that the design of the static class calls for it to be
stateful. This would be done when representing something that only one
instance exists for the duration of the program's execution (for example,
Application in ASP.NET would be completely viable as a static class, in my
opinion). Of course, one could make the argument that in this case a
singleton is preferable, since you could pass the singleton instance around.

Also, there is a purpose for non-static stateless methods. In COM+, for
example, if you were using transactions or JIT-activated implementations,
your design pretty much forced your instance methods to be stateless. Even
now, using remoting, your server's methods should be stateless in certain
activation scenarios (single-call, for example).

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Marc Gravell" <ma**********@gmail.com> wrote in message
news:eQ**************@TK2MSFTNGP04.phx.gbl...

for this scenario, any static members should be stateless

Your colleagure wouldn't be confusing this with the VB6 world, would they?
A .Net static class does *not* mean that an instance is created and
re-used for multiple callers. Quite the opposite. There /is/ no instance
("there is no spoon"); the methods are accessed via the type-definition
directly. This means that there is no need to instantiate or GC any
instances, which should theoretically lead to increased performance (I
haven't qualified this, as it would need some digging). However, the
difference is going to be so marginal (compared to everything else
happening) that I would opt for whatever keeps the system simplest.

That being said - there is never any purpose in having non-static
stateless methods (in fact, FxCop used to whinge at me for doing this...).

The real question is: is my usage stateless? Or do I rely on any static
fields / whatever. If your methods are stateless, then go static: you will
save a few lines of code and get some minor performance hits; nothing to
get excited over, though. If your methods are *not* stateless, then go
instance.

Marc

[Marc Gravell]

First - I'm not disagreeing with the previous poinnt.

OK, let me revise my statement then: stateful static methods should be very,
very careful about thread-safety; minimised lock times, that sort of thing.
I do, indeed, make use of stateful static classes, but you need to be
careful.

In the given (DAL) scenario, you could probably go a little either way
(depending on what exactly is meant); however, if one of the static fields
is the connection, then you are effectively forcing all your requests down a
single pipe - not ideal. It would be more efficient to let .Net pooling deal
with keeping the connections, and get on with writing the rest of the app.

Other differentiating features: static means you can't really use
inheritance, and you can only use interfaces via a singleton.

Marc

[Peter Bromberg [C# MVP]]

Raja,
To get back to the main point of your post (aside from the valid points
raised about being careful with static Fields carrying state) there should be
no perceptible performance difference between a static method and an
identical instance method.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Raja Chandrasekaran" wrote:

Marc Gravell wrote:

i.e. no static fields are updated

should have read
"no static fields are used"

Thanks for comment.its fine. But If I use Normal class with static
members and functions... what ll be the advantages and disadvantages...
Y I am aasking to increase the performance of my application by all the
ways...

[Tom Porterfield]

Peter Bromberg [C# MVP] wrote:

Raja,
To get back to the main point of your post (aside from the valid points
raised about being careful with static Fields carrying state) there
should be no perceptible performance difference between a static method
and an identical instance method.

If you are just talking about the method itself, then that is true. If you
are talking about total execution, then there is not enough information to
provide an answer. How much time does it take to create an instance of the
object? For example, is the object configurable, and it reads the
configuration from an external source? If so, creating an instance of the
object may take a perceptible amount of time, time that can be avoided or
greatly limited by using a different pattern.
--
Tom Porterfield

[Peter Bromberg [C# MVP]]

Tom,
Good point. This is not something I would spend my time writing tests for.
But, from what I have seen, in either case, the assembly must be loaded.
Object instantiation is probably the least time consuming operation in the
whole scheme of things, the CLR can instantiate 10 million objects in a
second.

In the IL, typicially the static method will be using the calll and the
instance method the callvirt instruction.

Callvirt does null checking of the object before it tries to invoke the
method.
So in that regard, static methods will be faster than instance methods,
since there is no null checking.

Again, the difference is so small as to be inconsequential, IMHO.

Regards,
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Tom Porterfield" wrote:

Peter Bromberg [C# MVP] wrote:

Raja,
To get back to the main point of your post (aside from the valid points
raised about being careful with static Fields carrying state) there
should be no perceptible performance difference between a static method
and an identical instance method.

If you are just talking about the method itself, then that is true. If you
are talking about total execution, then there is not enough information to
provide an answer. How much time does it take to create an instance of the
object? For example, is the object configurable, and it reads the
configuration from an external source? If so, creating an instance of the
object may take a perceptible amount of time, time that can be avoided or
greatly limited by using a different pattern.
--
Tom Porterfield

[Raja Chandrasekaran]

Thank you folks...

So there is no performance diff... But what about the memory issue...
Is there any diff... So Can I use any number of static classes or
methods... Or which situation is the best to use static method or class
and which is best for instance class...

[Barry Kelly]

"Raja Chandrasekaran" <Ra*****@gmail.com> wrote:

So there is no performance diff... But what about the memory issue...
Is there any diff... So Can I use any number of static classes or
methods... Or which situation is the best to use static method or class
and which is best for instance class...

Create an instance class if you need multiple instances with private
data per instance.

Create static properties when any shared state needs to be global.

Create static methods when the return value depends only on static
properties, static fields or the arguments.

Use a static class if there is no instance members in the class, only
static members.

-- Barry

--
http://barrkel.blogspot.com/