2

Earlier today I was doing some investigation and came across this article:

http://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-inefficiency-of-readonly-fields/

Which states that readonly fields are in fact inefficient, even if you have to look at a micro-optimization point of view.

Are there any other studies that confirm this? Should we be using readonly fields or is there an alternative that allows us to achieve the same results without losing efficiency in runtime?

Improve this question
2
  • 4
    Do note that the article states: "in a 64-bit CLR, but no RyuJIT". The findings are implementation dependent and subject to change. Commented Dec 29, 2015 at 12:58
  • I really appreciate you using the word investigate instead of research. I see countless people who think google-searching something is the same as researching it. Commented Dec 29, 2015 at 13:24

3 Answers 3

Reset to default
10

Should we be using readonly fields

Yes.

Because it adds self-documentation and self-verification to our code. The benefits of expressing the intent of a field far outweigh any (loss of) micro optimization.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

@Wouter, Jon does say This isn’t an optimization I’d recommend in general. Hold your horses.
It is a compile time solution for a runtime problem @WouterHuysentruit. Seems a good optimization to me.
@WouterHuysentruit "this is the first time that it’s had a practical impact on me" if it measurably affects you then it's no longer premature optimization. C# is certainly suited for applications requiring solid performance and besides -- the blogpost is about a C# library to start with. The answer is not to "just not make that library" at all.
Also in the article: I regard Noda Time as a sort of "system level" library which is the correct reason for this kind of optimization. The Fx library itself often goes against some best-practices for the sake of performance.
1

Is c# “readonly” really inefficient?

It depends on what kind of efficency is your concern.

Usually time spent on maintenance is the concern.

If you want to improve your code in nanoseconds or for high complexity situations, lower level languages can be options.. Because object orientation is firstly for maintainability, I think.

Try assembly :)

Improve this answer

Comments

0

Should we be using readonly fields

In the words of Jon Skeet, the highest rated SO poster, and from the post you linked

This isn’t an optimization I’d recommend in general. Most code really doesn’t need to be micro-optimized this hard...

And Jon said, let there be readonly fields.

is there an alternative that allows us to achieve the same results without losing efficiency in runtime?

Although this isn't the same as a readonly field, another similar option is to use a property with only a get accessor, and no set accessor. This will NOT allow you to set a value during construction (like you can with a readonly field) but the value still cannot be modified after that. If setting the property internally to the class is acceptable, then you can also have a private set accessor.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.