Есть ли разница в производительности между свойствами и полями поддержки в операциях чтения / записи?

Question

При работе в классе над его собственными полями и свойствами я обычно использую свойство только тогда, когда оно выполняет какую-то функцию (например, ограничение значения или проверку или что-то еще). В противном случае я предпочитаю читать / писать поле поддержки напрямую.

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

Помимо условностей или вкуса, существует ли фактический фактор эффективности между одним и другим методами?

Answer 1

Это действительно зависит. Технически это может быть медленнее, но даже в этих случаях это будет почти неприемлемо. Вот правила работы метода встраивания, взятые из здесь .

• Методы, длина которых превышает 32 байта, не будут встроены.
• Виртуальные функции не встроены.
• Методы, которые имеют сложное управление потоком, не будут встроены. Комплексное управление потоком - это любое управление потоком, кроме if / then / else; в этом случае переключитесь или пока.
• Методы, которые содержат блоки обработки исключений, не являются встроенными, хотя методы, которые генерируют исключения, все еще являются кандидатами для встраивания.
• Если какой-либо из формальных аргументов метода является структурой, метод не будет встроенным.

Поскольку компилятор C # создает отдельные методы getter и setter из объявления свойства, они, очевидно, будут обрабатываться независимо друг от друга. Исходя из приведенных выше правил, я бы сказал, что большинство методов доступа к свойствам встроены. Я думаю, что правило о том, что методы должны быть не виртуальными, было бы одним из нетривиальных показов, которые часто встречаются.

Answer 2

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

Тем не менее, get / sets может включать в себя любую логику, которую они хотят, поэтому может быть дорогостоящим - однако, рекомендации часто советуют сохранять их легкими.

Свойства имеют несколько преимуществ, даже если они просто получают /набор обложек:

• Привязка данных может видеть только свойства, а не поля.
• Это соответствует концепции инкапсуляции.
• Вы можете использовать только чтение или запись толькосемантика.
• Вы можете применять атрибуты отдельно к базовому полю (полезно в сценариях сериализации).

Просто в стороне, хотя интересно рассмотреть краткие характеристики производительности этихвещи - в производственном коде, применяющем этот тип оптимизации (ну, в данном случае его нет) вероятно попадет под знамя преждевременной оптимизации.

Answer 3

Если класс или структура предоставляют изменяемое поле типа структуры, можно получить доступ к отдельным полям этой структуры, не копируя все это.Напротив, если оно предоставляет свойство (изменяемое или нет) или поле «только для чтения», то доступ к любой части структуры приведет к тому, что система скопирует всю структуру, а затем получит доступ к копии.Кроме того, потребительский код может модифицировать поле открытого структурного поля удобно и эффективно без каких-либо избыточных операций копирования.Напротив, если структура представлена ​​как свойство, изменение любой ее части потребует от потребителя скопировать ее во временную переменную, внести изменения, а затем сохранить ее, последовательность шагов, которая, вероятно, вызовет всю структурукопируется четыре раза (по одному поставщику и потребителю при чтении и по одному при записи).

Answer 4

Не должно быть разницы в производительности.Если вы используете Reflector для анализа дизассемблирования кода, он автоматически создаст для вас поле поддержки самым простым способом.Это действительно просто синтаксический сахар, который ваш компилятор позволяет вам сделать жизнь проще.