Блог

Мне интересно, происходит ли какой-то JIT-взлом с System.Ленивый, чтобы сделать вещи более производительными или это чисто «обычный класс»?

Со страницы http://msdn.microsoft.com/en-us/library/dd642331.aspx в нем говорится:

Используйте экземпляр Lazy (из T), чтобы отложить создание большого или ресурсоемкого объекта или выполнение ресурсоемкой задачи, особенно когда такое создание или выполнение может не произойти в течение срока службы программы.

но я могу отложить выполнение ресурсоемкой задачи, используя простой логический флаг, не так ли? Итак, в чем именно разница? (кроме System.У Lazy есть дополнительные накладные расходы без видимого увеличения «синтаксического сахара»)

С простым логическим флагом это просто:

 if (!deferred) {
    //run resource-intensive task
}
  

Редактировать:

вот пример

 class Human{
    System.Lazy<String> name = new System.Lazy<String>(() =>
    {
        //code here takes 4 seconds to run
        return "the value";
    });
    String Name
    {
        get
        {
            return name.Value;
        }
    }
}
  

против

 class Human
{
    String name;
    bool name_initiated;
    String Name
    {
        get
        {
            if (!name_initiated)
            {
                //code here takes 4 seconds to run
                name = "the value";
                name_initiated = true;
            }
            return name;
        }
    }
}
  

6 Мая: теперь я часто использую это. И я действительно имею в виду очень много. я использую его всякий раз, когда мне нужно кэшировать данные (даже когда вычисление занимает 0,1 секунды или меньше). Отсюда мой вопрос, должен ли я беспокоиться? Теперь я знаю, что вы скажете мне профилировать приложение, но я сначала создаю библиотеку, прежде чем создавать приложение, и к тому времени, если в приложении возникнут проблемы, это будет означать серьезные изменения

Да, вы могли бы отложить это с помощью простого логического флага. Конечно, вам нужно было бы обрабатывать изменчивость как флага, так и результата … и убедиться, что вы знали, чего хотите с точки зрения результата, если один поток запрашивает результат, пока он все еще вычисляется. О, и постарайтесь избегать блокировки, где это возможно. И сделать все это пуленепробиваемым с точки зрения потокобезопасности.

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

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

Другим хорошим примером этого принципа является Nullable<T> . Вы могли бы легко получить большую часть того же поведения самостоятельно (не упаковывать) или даже вообще не беспокоиться об инкапсуляции и просто сохранить флаг рядом с вашим обычным полем… но со встроенным типом вы получаете все это реализованным бесплатно, вместе с синтаксическим сахаром и т.д.

Класс Lazy упрощает процесс. Это похоже на использование строки вместо массива символов. Технически это не обязательно, но может быть полезно.

Lazy<T> это просто инкапсуляция наилучшего способа реализации ленивого синглтона. Если вы хотите потокобезопасности, это нечто большее, чем просто if(!initialized) instance = Initialize(); . Я обычно предполагаю, что команда BCL будет лучше в реализации, чем я.

Обновление: Основываясь на вашем примере, я бы сказал, что преимущество Lazy<> заключается просто в меньшем количестве кода для поддержки. Помимо этого, они по существу эквивалентны. Мой совет: используйте Lazy<> , потому что это легко, и переходите к более сложным задачам.

Класс Lazy выполняет всю работу по обеспечению потокобезопасности за вас, что является чем-то намного более сложным, чем кажется, для реализации вручную.