I have a question about Constant and static variable. We are developing a project in asp.net 2.0. This project code behind is in VB.net. In this we are using around 600 "Shared Readonly" variables.
All variables are "String" type. All variables are holding constant values.
In this scenario, which one will give better performance,
Constant OR
Static variable
Please explain the memory Consumption and storing/retriving details
Contatnt will give better performance, because that is build at compile time and however store 600 variable in shared variable mean your server side memory for common for all so that is not good idea.
So here I can suggest for this kind of thing you can store this all kind of data in database or chache or xml file and retirve based on your need.
My Tech Blogs MCPD Enterprise and Web Application
MCTS Web, Window and Enterprise Application
In this scenario, which one will give better performance,
Strictly speaking a Constant should have slightly better performance (1 nanosecond instead of 2 probably) because it's value is set at compile-time whereas a static readonly value is loaded at runtime.
However the bigger picture question here is which is the more proper
way of creating and using these values. Performance while key is leaving out the entire issue of when it it appropriate to use either a Constant or a Static/Shared Readonly value.
Stating something is a 'Constant' is saying: "The value is X, and it will always and forever be 'X' and never change."
Often you will see constants used in API constants (amoung a zillion other things) as shown below:
Public Const MAPI_E_DISK_FULL = 4
Above, you know the value will always be '4' and never change. This is where it is best to use a Constant value.
A Shared Readonly' variable will be set an runtime and then never change throughout its lifetime of that application instance. It has strength in being able to be dynamically set at runtime. Something that comes to mind might be some type of environmental or user value like displayed below:
Public Shared ReadOnly Property MachineName As String
Get
Return My.Computer.Name
End Get
End Property
Obviously we do not want any part of the application to set the name of the computer and thus we need a 'ReadOnly' variable, but at the same time its return value
is not constant. It will be different depending on where the application is run in the case of the code above.
So you see it is more than just about performance. There are legitimate uses for either a Constant or a Shared Readonly variable and mixing usage may create confusion for developers following behind you so it's best to pick the option that is appropriate
and makes sense.
Is it'll create separate TOKEN for each user or the TOKEN will be shared by all user?
If it was a Constant than 'yes'. If it is a read-only variable determined at runtime, then it depends on how you create it. If you are asking what you should use (separate vs shared) that should be based on your requirements.
subalakshmi.ms
If it is creating separate TOKEN for each user, then how much memory will be consumed by the TOKEN?
Hard to say, that is based on the number of users. You can always use the Performance Monitor tool in Windows to pull metrics on your applications performance.
subalakshmi.ms
When the TOKENs are removed from memory?
Depends on how you construct and dispose of them. If they are constants they may never be removed from memory. Other types on instances will be handled by the .NET garbage collection.
At this point if your original question has been answered and you have new
questions, please finish off this question 1st and start a new thread so it is easier to manage and understand for future readers.
subalakshmi....
Member
597 Points
130 Posts
Constant Vs Shared/Static Variable
Apr 25, 2012 10:00 AM|LINK
I have a question about Constant and static variable. We are developing a project in asp.net 2.0. This project code behind is in VB.net. In this we are using around 600 "Shared Readonly" variables.
All variables are "String" type. All variables are holding constant values.
In this scenario, which one will give better performance,
Please explain the memory Consumption and storing/retriving details
Thanks in advance
Cognizant
nijhawan.sau...
All-Star
16400 Points
3173 Posts
Re: Constant Vs Shared/Static Variable
Apr 25, 2012 10:09 AM|LINK
Performance comparison:
http://stackoverflow.com/questions/3190870/const-string-vs-static-string-in-c-sharp
amitpatel.it
Star
7946 Points
1865 Posts
Re: Constant Vs Shared/Static Variable
Apr 25, 2012 10:16 AM|LINK
Contatnt will give better performance, because that is build at compile time and however store 600 variable in shared variable mean your server side memory for common for all so that is not good idea.
So here I can suggest for this kind of thing you can store this all kind of data in database or chache or xml file and retirve based on your need.
MCPD Enterprise and Web Application
MCTS Web, Window and Enterprise Application
atconway
All-Star
16846 Points
2756 Posts
Re: Constant Vs Shared/Static Variable
Apr 25, 2012 07:12 PM|LINK
Strictly speaking a Constant should have slightly better performance (1 nanosecond instead of 2 probably) because it's value is set at compile-time whereas a static readonly value is loaded at runtime.
However the bigger picture question here is which is the more proper way of creating and using these values. Performance while key is leaving out the entire issue of when it it appropriate to use either a Constant or a Static/Shared Readonly value.
Stating something is a 'Constant' is saying: "The value is X, and it will always and forever be 'X' and never change." Often you will see constants used in API constants (amoung a zillion other things) as shown below:
Above, you know the value will always be '4' and never change. This is where it is best to use a Constant value.
A Shared Readonly' variable will be set an runtime and then never change throughout its lifetime of that application instance. It has strength in being able to be dynamically set at runtime. Something that comes to mind might be some type of environmental or user value like displayed below:
Public Shared ReadOnly Property MachineName As String Get Return My.Computer.Name End Get End PropertyObviously we do not want any part of the application to set the name of the computer and thus we need a 'ReadOnly' variable, but at the same time its return value is not constant. It will be different depending on where the application is run in the case of the code above.
So you see it is more than just about performance. There are legitimate uses for either a Constant or a Shared Readonly variable and mixing usage may create confusion for developers following behind you so it's best to pick the option that is appropriate and makes sense.
Hope this helps!
subalakshmi....
Member
597 Points
130 Posts
Re: Constant Vs Shared/Static Variable
Apr 26, 2012 07:00 AM|LINK
Thank You So much atconway.
I have some other questions that,
Constants are accessed by using TOKEN of type Integer.
Kindly clarify my questions.
Once again Thanks for your detailed informative reply.
Cognizant
atconway
All-Star
16846 Points
2756 Posts
Re: Constant Vs Shared/Static Variable
Apr 26, 2012 05:59 PM|LINK
If it was a Constant than 'yes'. If it is a read-only variable determined at runtime, then it depends on how you create it. If you are asking what you should use (separate vs shared) that should be based on your requirements.
Hard to say, that is based on the number of users. You can always use the Performance Monitor tool in Windows to pull metrics on your applications performance.
Depends on how you construct and dispose of them. If they are constants they may never be removed from memory. Other types on instances will be handled by the .NET garbage collection.
At this point if your original question has been answered and you have new questions, please finish off this question 1st and start a new thread so it is easier to manage and understand for future readers.
subalakshmi....
Member
597 Points
130 Posts
Re: Constant Vs Shared/Static Variable
Apr 27, 2012 10:03 AM|LINK
Hi,
Thank You So much for reply
Cognizant