Предоставление GUID через статическое свойство - эффективнее ли использовать старомодный синтаксис свойства - PullRequest
Новая
       1

Предоставление GUID через статическое свойство - эффективнее ли использовать старомодный синтаксис свойства

0 голосов
/ 23 ноября 2011

У меня есть статический класс C #, который предоставляет некоторые ранее известные Guids через свойства

Я использовал старомодный синтаксис свойства, например, частное объявление, которое объявляет guid, и открытое свойство, которое его выставляет.например, что-то вроде 

 private static Guid aGuid = new Guid("l1....");
public static Guid AGuid { get { return aGuidl }}

Но было бы меньше кода только для того, чтобы иметь автоматическое свойство, например 

public static Guid  AGuid { get{ return new Guid("11...") }}

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

Ответы [ 2 ]

3 голосов
/ 23 ноября 2011

Кэширование (ваш 1-й пример) будет немного более эффективным здесь.

Компилятор не будет делать это как оптимизацию.

Я только что проверил с Ildasm.

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

0 голосов
/ 23 ноября 2011

Необходимая преамбула:

  1. Как и большинство микрооптимизаций, ответ, вероятно, "кого это волнует?" Вряд ли это будет причиной замедления вашей программы.
  2. Это простая вещь, чтобы сделать быстрый эмпирический тест. Однако, как и все эмпирические тесты, вы должны скептически относиться к своим результатам. Ответ может зависеть от множества ненаблюдаемых или ненаблюдаемых ошибок.

Хенк Холтерман прав, что ИЛ будет казаться более эффективным в первой форме. Конструктор, который принимает строку, должен выполнить некоторый анализ. Разбор не медленный, но и не бесплатный. Можно было бы легко улучшить производительность, используя конструктор Guid, который принимает строковые типы int вместо строки.

Кроме того, Guid является типом значения. Это означает, что несмотря ни на что, вам придется заплатить стоимость копирования памяти, когда вы вернете Guid (да, я знаю, это действительно крутая плата за копирование 16 байт).

Наконец, и здесь я получаю немного предположения, вполне возможно, что JITer может распознавать конструкторы, не имеющие побочных эффектов, и развертывать их во время JIT в «простые старые данные». Если это так, то общая стоимость может составить всего 16 байтов memcpy, что в любом случае неизбежно.

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

...