Фактическая производительность полей и свойств
Я делаю некоторые после сборки CIL weaving, который добавляет CIL ко всем методам в сборке (другими словами, тонны методов). Каждый метод проверяет, является ли определенное значение null. Пример (на C# отражатель бы версию CIL-код):
// CIL woven region start
if (MyType.Something == null) {
// ... some new stuff
}
// CIL woven region end
Как влияет на производительность наличие MyType.Что-то как собственность против Поля? Я знаю, что читал, что компилятор C# выполняет специальные оптимизации, и в этом случае не должно быть никакого влияния на производительность...но как быть в случае прямого CIL-код (без компилятора C#)...? Или это компилятор JIT, который позволяет эти оптимизации (так что прямой CIL-код по-прежнему выигрывает)?
будет испускать код операции.Вызов метода доступа к статическому свойству имеет более низкую производительность, чем Ldsfld (имейте в виду, что это через десятки тысяч вызовов, так как каждый метод в сборке сплетен)?
спасибо.
3 ответов
при разработке математической библиотеки для SlimDX мы обнаружили, что pre-.NET 3.5 фреймворки SP1, использующие поля для членов математических типов (например, X, Y, Z для Вектора 3), дали непропорциональное увеличение производительности по сравнению со свойствами. Другими словами, разница была заметна для небольших математических функций, которые сильно обращались к свойствам.
с тех пор это было улучшено с .NET 3.5 SP1 (см. Джит inling). Хотя я считаю, что JIT до этого будет все еще встроенные небольшие методы (свойства-это просто методы в конце концов), есть ошибка в более ранних фреймворках, которая предотвратила вставку методов, которые принимают или возвращают типы значений.
обратите внимание, что разница, когда там еще совсем маленький. Я бы все равно предпочел использовать свойства во всех, кроме самых критических случаев производительности.
компилятор C# не оптимизирует это, нет, но компилятор JIT обычно может встроить тривиальные (и не виртуальные) свойства, насколько мне известно.
Как и со всеми вопросами производительности, хотя: когда сомневаетесь, проверьте!
эффект незначителен в любом направлении. Если ваши свойства выглядят следующим образом::
public static SomeType PropertyName
{
get {return MyType.propertyName;}
set {MyType.propertyName = value;}
}
там действительно должна быть очень незначительная разница. Компилятор Jit должен встроить call
MyType.set_Property
в полевую нагрузку, но даже если это не удалось из-за ошибки. Я лично ошибаюсь на стороне осторожности и придерживаюсь сеттеров свойств и геттеров, поскольку потенциально тело метода может измениться, и в результате доступ к необработанному полю/мутация могут быть недостаточными.
если вы хотите проверить, вы можете заставить метод излучают использовать MethodImpl
отключения встраивание и оптимизации. И затем сравните разницу, я действительно сомневаюсь, что это будет значительным.