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

"Christof Nordiek" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

"Tim Haughton" <(E-Mail Removed)> schrieb im Newsbeitrag
newskzXe.129274$(E-Mail Removed)...
> "Christof Nordiek" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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

> 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

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]
- (E-Mail Removed)

"Christof Nordiek" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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
private.php?do=newpm&u=
sip:(E-Mail Removed)
-=> Sebastian cover-music: http://ungdomshus.nu <=-

"Nicholas Paldino [.NET/C# MVP]" <(E-Mail Removed)> wrote in
message news:(E-Mail Removed)...
> 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

"Tim Haughton" <(E-Mail Removed)> wrote in message
news:kzOXe.144821$(E-Mail Removed)...
> 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

> 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

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