Доступ к переменной элемента напрямую через свойство

Question

Я задаю этот вопрос с характеристиками в качестве основной проблемы. Но я хотел бы узнать другие возможные преимущества/недостатки для обоих подходов.

Вопрос: Поскольку свойства преобразуются в методы в IL, может ли быть значительное снижение производительности, если свойства вызываются вместо прямого доступа к полям (из класса)?

Я проектирую класс преобразования (PersonalizationConstructor), цель которого - «создать объект домена» из IDataReader.

Я собираюсь принять IDataReader в конструкторе этого класса (PersonalizationConstructor) и защитить виртуальные свойства для возврата данных из набора записей IDataReader; например:

protected virtual string ProductFilterCriteria 
{ 
    get; 
    set; 
} 

Я мог бы иметь 15+ объектов в одном классе для этой реализации. Таким образом, свойство может быть переопределено, чтобы проверить, имеет ли набор записей «XXX» поле перед доступом из набора записей (я не хочу, чтобы такая проверка выполнялась по умолчанию для всех).

Хорошо ли иметь 15+ виртуальных объектов в классе для реализации вышеприведенного случая?

---

Не обращайте внимания на IDataReader. Моя главная забота:

Поскольку свойства преобразуются в методы в IL, мог быть значительным производительность штрафом, если свойств называется вместо доступа к полям непосредственно (внутри класса)?

Я бы иметь что-то вроде этого:

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; 
     } 
    } 
} 

Answer 1

Установка или извлечение имущества, которая реализуется с C# 3.0 синтаксис собственности или старого стиля с наклеенной поле, может (но не обязательно) быть оптимизированный JIT. Это означает, что любая оптимизация в этом отношении не будет измерима или даже может быть контрпродуктивной.

Вы говорите о свойствах, которые относятся к типу класса (в отличие от примитивного типа, такого как int из float). Накладные расходы этих классов (ctor) или время, затрачиваемое на выполнение совершенно разных вещей (вы указываете IDataReader, который, как я полагаю, читает данные, что дорого) намного больше, чем возможные 1 или 2 μ-ops, которые вы можете сэкономить, изменив свойство в поле. То, что я получаю: это как прибыль 0.001%, если даже.

Другими словами: хотя в очень редких ситуациях, когда вы находитесь во внутреннем цикле и должны выдавливать каждую микросекунду, вы можете пересмотреть этот выбор. В любых других ситуациях: используйте gettors/settors.

PS: чтение другого ответа на этот q. заставляет меня думать, что я, возможно, неправильно понял. Если да, просто оставьте комментарий

EDIT: Джон С. упоминает, что виртуальные свойства не оптимизированы, что верно.Но сюжетная линия на минорной прибыль остается вне

Answer 2

Вы, вероятно, хотите, чтобы принять IDataRecord, а не IDataReader, так как это «базовый тип», который описывает часть в DataReader, что вы заботитесь о.

В противном случае, я бы просто использовал свойства. Все будет хорошо. Я бы не отметил их «виртуальными». Коэффициенты этого типа на самом деле не предназначены для наследования, и если это такие свойства, вероятно, не следует трогать.

Answer 3

Как всегда, прежде чем принимать дизайнерские решения, основанные на производительности, измерьте его!

Предполагая, что данные поступают из реляционной базы данных, сильно подозревают, что сам запрос (и связанные с ним преобразования, сетевой IO и т. Д.) Будет доминировать над производительностью.

JIT не сможет подключаться к виртуальным виртуальным вызовам свойств, но если причина использования виртуальных свойств заключается в том, что разные реализации могут потребоваться для разных целей, у вас действительно нет возможности использовать прямой доступ к полю.

Я бы не хотел сказать, хорош ли ваш дизайн или нет - на самом деле у нас недостаточно информации, но если вы считаете, что это самый читаемый способ реализации того, что вам нужно, тогда создайте прототип и измерьте его прежде чем отклониться от этой конструкции.