Издержки использования этого на структурах

Question

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

Если вы не используете автоматические свойства, а просто объявляете значения, вы можете избежать использования конструктора this.

Каковы издержки использования this для конструкторов в структурах? Это то же самое, что двойная инициализация значений?

Вы бы порекомендовали не использовать его, если производительность была основной проблемой для этого конкретного типа?

Answer 1

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

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

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

Возвращаясь к исходному вопросу: если вы заботитесь о производительности, измерьте ее . Всегда. В этом случае это действительно просто - вы можете написать структуру, используя автоматическое свойство, а затем переопределить ее без. Вы можете использовать блок #if, чтобы сохранить обе опции доступными. Затем вы можете измерить типичные ситуации и посмотреть, является ли разница существенной. Конечно, я думаю, что последствия для дизайна, скорее всего, будут более важными:)

Answer 2

Да, значения будут инициализированы дважды, и без профилирования трудно сказать, будет ли это снижение производительности значительным.

Конструктор по умолчанию struct инициализирует все элементы к их значениям по умолчанию. После этого ваш конструктор запустится, и вы, несомненно, снова установите значения этих свойств.

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

Answer 3

Не используйте автоматические свойства с типами структуры. Просто выставьте поля напрямую. Если структура имеет открытое открытое поле Foo типа Bar, тот факт, что Foo является открытым полем типа Bar (информация, легко доступная в Intellisense), говорит практически обо всем, что нужно знать об этом. , Напротив, тот факт, что структура Foo имеет открытое свойство чтения-записи Boz, ничего не говорит о том, будет ли запись в Boz видоизменять поле в структуре или мутирует ли какой-либо объект, для которого Boz содержит ссылку. Прямой доступ к полям обеспечит более чистую семантику и часто также приводит к более быстрому выполнению кода.

Answer 4

Причина, по которой компилятор C # требует, чтобы вы связались с конструктором по умолчанию (т. Е. Добавляете : this() к вашему объявлению конструктора) при использовании автоматически реализуемых свойств, заключается в том, что все переменные должны быть назначены до выхода из конструктора . Теперь автоматически внедряемые свойства портят это из-за того, что они не позволяют вам напрямую обращаться к переменным, которые поддерживают свойства . Метод, который компилятор использует, чтобы обойти это, состоит в том, чтобы автоматически назначать все переменные их значениям по умолчанию, и чтобы это гарантировать, вы должны связать конструктор по умолчанию. Это не очень умный метод, но он выполняет свою работу достаточно хорошо.

Так что, действительно, это будет означать, что некоторые переменные будут инициализированы дважды. Тем не менее, я не думаю, что это будет большой проблемой производительности. Я был бы очень удивлен, если бы компилятор (или, по крайней мере, JIT) не просто удалил первый оператор инициализации для любой переменной, которая была дважды установлена ​​в вашем конструкторе. Быстрый тест должен подтвердить это для вас, хотя я совершенно уверен, что вы получите ожидаемые результаты. (Если вы случайно этого не сделаете, и вам абсолютно необходимо небольшое повышение производительности, которое позволяет избежать дублирования предложений инициализации, вы можете просто определить свои свойства обычным способом, то есть с помощью вспомогательных переменных.)

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

Надеюсь, это поможет.