constants vs. readonly-fields

[Christof Nordiek]

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

 

[Tim Haughton]

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

 

[Christof Nordiek]

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

 

[Tim Haughton]

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

 

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

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.

 

[Helge Jensen]

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.

 

[Tim Haughton]

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

 

[Michael S]

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

 

[Tim Haughton]

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

 

[Michael S]

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

 

[Tim Haughton]

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

 

[Michael S]

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