I am asking this question with performance as main concern. But I would like to know other possible advantages / disadvantages for both approaches.
The question is: Since properties are converted to methods in IL, could there be significant performance penalty if properties are called instead of accessing fields directly (from within class)?
I am designing a transformation class (PersonalizationConstructor) whose whole purpose is to “construct domain e开发者_如何学Pythonntity” from IDataReader.
I am thinking to accept IDataReader in constructor of this class (PersonalizationConstructor) and have protected virtual properties to return data from IDataReader record set; like:
protected virtual string ProductFilterCriteria
{
get;
set;
}
I could have 15+ properties in one class for this implementation. This way, a property could be overridden to check if record set has “XXX” field before accessing from record set (I do not want to have such check as default implementation for all).
Is it good to have 15+ virtual properties in a class for implementing above case?
Please do not focus much on IDataReader. My main concern is:
Since properties are converted to methods in IL, could there be significant performance penalty if properties are called instead of accessing fields directly (from within class)?
I would be having something like this:
class MainSite
{
protected virtual string ProductFilterCriteria
{
get
{
return _source["ProductFilterCriteria"];
}
}
protected virtual string Abc
{
get
{
return _source["Abc"];
}
}
protected virtual string Def
{
get
{
return _source["Def"];
}
}
..... many properties
}
class VirtualSite : MainSite
{
protected override string ProductFilterCriteria
{
get
{
return null;
}
}
}
As ever, before you make design decisions based on performance - measure it!
Assuming the data is coming from a relational database, I strongly suspect that the query itself (and associated conversions, network IO etc) is going to dominate performance.
The JIT isn't going to be able to inline virtual property calls, but if the reason for using virtual properties is that different implementations might need to do different things, you really don't have the option of using direct field access anyway.
I wouldn't like to say whether your design is good or not - we don't really have enough information - but if you think it's the most readable way of implementing what you need, then build a prototype and measure its performance before deviating from that design.
You probably want to accept an IDataRecord
rather than IDataReader
, since that is the "base type" that describes the portion of a DataReader that you will care about.
Otherwise, I would just use properties. It will be okay. I would not mark them "virtual". Odds are this type isn't really intended to be inherited, and if it is these properties probably shouldn't be touched.
Setting or retrieving a property that's implemented with the C# 3.0 property syntax, or old-style backed with a field, can (but not necessarily will) be optimized away by the JIT. That means that any optimizations in this respect will not be measurable or may even be counter-productive.
You are talking of properties that take a class type (as opposed to a primitive type like int
of float
). The overhead of these classes (ctor) or the time spend in doing totally different things (you mention IDataReader
which I assume reads data, which is expensive) are so much larger then the possible 1 or 2 µ-ops you might safe by changing from property to field. What I'm getting at: that's like 0.001% profit, if even.
In other words: though in very rare situations where you're in an inner loop and must squeeze out every microsecond, you can reconsider this choice. In any other situations: use gettors / settors.
PS: reading the other answer to this q. makes me think I perhaps misunderstood. If so, just leave a comment
EDIT: Jon S. mentions that virtual properties are not optimized away, which is correct. But the story-line on the minor profit remains regardless
精彩评论