By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,876 Members | 1,239 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,876 IT Pros & Developers. It's quick & easy.

constants vs. readonly-fields

P: n/a
Hi all,

Can there be a performance difference, if i use readonly fields instead of
constants?

e.g.:
const int n = 100;
vs.
static readonly int = 100;

or
const string s = "text";
vs.
static readonly string s = "text";

Christof
Nov 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
"Christof Nordiek" <cn@nospam.de> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Hi all,

Can there be a performance difference, if i use readonly fields instead of
constants?

e.g.:
const int n = 100;
vs.
static readonly int = 100;

or
const string s = "text";
vs.
static readonly string s = "text";


I haven't profiled it first hand, but I'd suggest that *if* there's any
difference, the const will be faster since it is compile time initialised,
whereas a static read only field is runtime initialised (as it can be
assigned by static constructors.).

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
Nov 17 '05 #2

P: n/a
"Tim Haughton" <ti*********@gmail.com> schrieb im Newsbeitrag
news:Dk*******************@fe08.news.easynews.com. ..
"Christof Nordiek" <cn@nospam.de> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Hi all,

Can there be a performance difference, if i use readonly fields instead
of
constants?

e.g.:
const int n = 100;
vs.
static readonly int = 100;

or
const string s = "text";
vs.
static readonly string s = "text";


I haven't profiled it first hand, but I'd suggest that *if* there's any
difference, the const will be faster since it is compile time initialised,
whereas a static read only field is runtime initialised (as it can be
assigned by static constructors.).

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

Thanks for answering.
Your talking about initialization.
But what about accessing those fields/constants.

Christof
Nov 17 '05 #3

P: n/a
> Thanks for answering.
Your talking about initialization.
But what about accessing those fields/constants.


I can't see there being a reason for any discrepency in access times. Once
they're created, they're just members that can't be touched.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
Nov 17 '05 #4

P: n/a
Christof,

Accessing n will be faster, because when you compile an assembly with a
reference to the assembly containing that constant, that value is
substituted into the code. With readonly fields, you have to actually do a
lookup.

I hope you aren't trying to do this in the hopes of optimizing your
code. It sounds premature, unless you have some performance numbers to back
it up otherwise.

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

"Christof Nordiek" <cn@nospam.de> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
Hi all,

Can there be a performance difference, if i use readonly fields instead of
constants?

e.g.:
const int n = 100;
vs.
static readonly int = 100;

or
const string s = "text";
vs.
static readonly string s = "text";

Christof

Nov 17 '05 #5

P: n/a


Christof Nordiek wrote:
Hi all,

Can there be a performance difference, if i use readonly fields instead of
constants?


Try measuring the performance of your program with a profiler instead of
focusing on small things like this.

It will probably not make much (performance) difference if your program
uses a readonly field or a constant.

Before you use performance as the reason for syntactic choices you
should verify that performance affected by this choice is an issue.

--
Helge Jensen
mailto:he**********@slog.dk
sip:he**********@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-
Nov 17 '05 #6

P: n/a
"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:e6**************@TK2MSFTNGP12.phx.gbl...
Christof,

Accessing n will be faster, because when you compile an assembly with a reference to the assembly containing that constant, that value is
substituted into the code. With readonly fields, you have to actually do a lookup.


Hi Nicholas, I hadn't realised that this was what the compiler did. How does
this work if the version of the referenced assembly changes, by policy or
other means? Say, for example, the constant is a different value in the new
version of the referenced assembly, how does this new version percolate
through to the client without a rebuild?

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
Nov 17 '05 #7

P: n/a

"Tim Haughton" <ti*********@gmail.com> wrote in message
news:kz*******************@fe08.news.easynews.com. ..
Say, for example, the constant is a different value in the new
version of the referenced assembly, how does this new version percolate
through to the client without a rebuild?


It would not. You need a rebuild of all calling assemblies. Who are they?
This is one of the dangers with constants. Why I would never sport a public
constant. I'd rather go for static readonly

- Michael S

Nov 17 '05 #8

P: n/a
> It would not. You need a rebuild of all calling assemblies. Who are they?
This is one of the dangers with constants. Why I would never sport a public constant. I'd rather go for static readonly


That's an interesting design decision by Microsoft. I wonder if the
motivation was performance. It seems to be a tiny performance gain for a
non-trivial deployment consideration.

But like you say, I don't think I've ever delivered anything with a public
const field so it's unlikely to become an issue.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
Nov 17 '05 #9

P: n/a
Another comment on constants.
Just use them for true constants

const double PI = 3.14; // Good. Won't change, except very close to the
apocalypse. System will survive the universe.
const int CustomerNameLength = 30; // Bad. This number may change when
requirements changes.

- Michael S
Nov 17 '05 #10

P: n/a
"Michael S" <a@b.c> wrote in message
news:ul**************@TK2MSFTNGP09.phx.gbl...
Another comment on constants.
Just use them for true constants

const double PI = 3.14; // Good. Won't change, except very close to the
apocalypse. System will survive the universe.
const int CustomerNameLength = 30; // Bad. This number may change when
requirements changes.


You're making gross assumptions about the absence of space time variations
and adherence to Euclidean geometry. Although, I'll grant you, if there was
sufficient local space time curvature giving rise to such deviations from
Euclidean geometry, the backwards compatibility of my software would
probably be very low on my agenda.

;)

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton
Nov 17 '05 #11

P: n/a

"Tim Haughton" <ti*********@gmail.com> wrote in message
news:yU********************@fe05.news.easynews.com ...
"Michael S" <a@b.c> wrote in message
news:ul**************@TK2MSFTNGP09.phx.gbl...
Another comment on constants.
Just use them for true constants

const double PI = 3.14; // Good. Won't change, except very close to the
apocalypse. System will survive the universe.
const int CustomerNameLength = 30; // Bad. This number may change when
requirements changes.


You're making gross assumptions about the absence of space time variations
and adherence to Euclidean geometry. Although, I'll grant you, if there
was
sufficient local space time curvature giving rise to such deviations from
Euclidean geometry, the backwards compatibility of my software would
probably be very low on my agenda.

;)


LOL!

And considering that most computers would not like 'deviations from
Euclidean geometry' I think we can safely write this off as a Hardware
Problem =)

- Michael S
Nov 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.