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]

Re: constants vs. readonly-fields

"Christof Nordiek" <cn@nospam.de > wrote in message
news:uc0og4RvFH A.2008@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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";[/color]

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]

Re: constants vs. readonly-fields

"Tim Haughton" <timhaughton@gm ail.com> schrieb im Newsbeitrag
news:DkzXe.1292 74$e95.3777@fe0 8.news.easynews .com...[color=blue]
> "Christof Nordiek" <cn@nospam.de > wrote in message
> news:uc0og4RvFH A.2008@TK2MSFTN GP10.phx.gbl...[color=green]
>> 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";[/color]
>
> 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
>
>[/color]
Thanks for answering.
Your talking about initialization.
But what about accessing those fields/constants.

Christof

[Tim Haughton]

Re: constants vs. readonly-fields

> Thanks for answering.[color=blue]
> Your talking about initialization.
> But what about accessing those fields/constants.[/color]

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]]

Re: constants vs. readonly-fields

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]
- mvp@spam.guard. caspershouse.co m

"Christof Nordiek" <cn@nospam.de > wrote in message
news:uc0og4RvFH A.2008@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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
>[/color]

[Helge Jensen]

Re: constants vs. readonly-fields



Christof Nordiek wrote:[color=blue]
> Hi all,
>
> Can there be a performance difference, if i use readonly fields instead of
> constants?[/color]

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:helge.je nsen@slog.dk
sip:helge.jense n@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Tim Haughton]

Re: constants vs. readonly-fields

"Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard .caspershouse.c om> wrote in
message news:e6C7B9SvFH A.1032@TK2MSFTN GP12.phx.gbl...[color=blue]
> Christof,
>
> Accessing n will be faster, because when you compile an assembly with[/color]
a[color=blue]
> reference to the assembly containing that constant, that value is
> substituted into the code. With readonly fields, you have to actually do[/color]
a[color=blue]
> lookup.[/color]

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]

Re: constants vs. readonly-fields


"Tim Haughton" <timhaughton@gm ail.com> wrote in message
news:kzOXe.1448 21$e95.8290@fe0 8.news.easynews .com...[color=blue]
> 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?[/color]

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]

Re: constants vs. readonly-fields

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

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]

Re: constants vs. readonly-fields

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 CustomerNameLen gth = 30; // Bad. This number may change when
requirements changes.

- Michael S

[Tim Haughton]

Re: constants vs. readonly-fields

"Michael S" <a@b.c> wrote in message
news:ulluYYcvFH A.1256@TK2MSFTN GP09.phx.gbl...[color=blue]
> 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 CustomerNameLen gth = 30; // Bad. This number may change when
> requirements changes.[/color]

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]

Re: constants vs. readonly-fields


"Tim Haughton" <timhaughton@gm ail.com> wrote in message
news:yUQXe.1141 00$0I4.11284@fe 05.news.easynew s.com...[color=blue]
> "Michael S" <a@b.c> wrote in message
> news:ulluYYcvFH A.1256@TK2MSFTN GP09.phx.gbl...[color=green]
>> 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 CustomerNameLen gth = 30; // Bad. This number may change when
>> requirements changes.[/color]
>
> 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.
>
> ;¬)[/color]

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