Правильное использование "доходности"
Ключевое слово yield - это одно из тех ключевых слов в C#, которое продолжает меня удивлять, и я никогда не был уверен, что использую его правильно.
Из следующих двух частей кода, который является предпочтительным и почему?
Версия 1: Использование возврата доходности
public static IEnumerable<Product> GetAllProducts()
{
using (AdventureWorksEntities db = new AdventureWorksEntities())
{
var products = from product in db.Product
select product;
foreach (Product product in products)
{
yield return product;
}
}
}
Версия 2: вернуть список
public static IEnumerable<Product> GetAllProducts()
{
using (AdventureWorksEntities db = new AdventureWorksEntities())
{
var products = from product in db.Product
select product;
return products.ToList<Product>();
}
}
17 ответов
Я склонен использовать доходность при вычислении следующего элемента в списке (или даже следующей группы элементов).
Используя вашу версию 2, вы должны иметь полный список, прежде чем вернуться. Используя yield-return, вам действительно нужно иметь только следующий товар перед возвратом.
Среди прочего, это помогает распределить вычислительные затраты на сложные вычисления в течение большего периода времени. Например, если список подключен к графическому интерфейсу, и пользователь никогда не переходит на последнюю страницу, вы никогда не вычисляете конечные элементы в списке.
Другой случай, когда доходность-возврат предпочтительнее, это когда IEnumerable представляет бесконечное множество. Рассмотрим список простых чисел или бесконечный список случайных чисел. Вы никогда не сможете вернуть полный IEnumerable сразу, поэтому вы используете yield-return для постепенного возврата списка.
В вашем конкретном примере у вас есть полный список продуктов, поэтому я бы использовал версию 2.
Заполнение временного списка похоже на загрузку всего видео, тогда как использование yield это как потоковое видео.
В качестве концептуального примера для понимания, когда вы должны использовать yieldскажем метод ConsumeLoop() обрабатывает элементы, возвращенные / выданные ProduceList():
void ConsumeLoop() {
foreach (Consumable item in ProduceList()) // might have to wait here
item.Consume();
}
IEnumerable<Consumable> ProduceList() {
while (KeepProducing())
yield return ProduceExpensiveConsumable(); // expensive
}
Без yieldПризыв к ProduceList() может занять много времени, потому что вы должны заполнить список перед возвратом:
//pseudo-assembly
Produce consumable[0] // expensive operation, e.g. disk I/O
Produce consumable[1] // waiting...
Produce consumable[2] // waiting...
Produce consumable[3] // completed the consumable list
Consume consumable[0] // start consuming
Consume consumable[1]
Consume consumable[2]
Consume consumable[3]
С помощью yieldпереставляем, вроде как работаем "параллельно":
//pseudo-assembly
Produce consumable[0]
Consume consumable[0] // immediately Consume
Produce consumable[1]
Consume consumable[1] // consume next
Produce consumable[2]
Consume consumable[2] // consume next
Produce consumable[3]
Consume consumable[3] // consume next
И, наконец, как уже предлагали многие, вы должны использовать версию 2, потому что у вас уже есть заполненный список.
Я знаю, что это старый вопрос, но я хотел бы предложить один пример того, как можно творчески использовать ключевое слово yield. Я действительно извлек выгоду из этой техники. Надеюсь, это поможет любому, кто наткнется на этот вопрос.
Примечание. Не думайте, что ключевое слово yield является просто еще одним способом создания коллекции. Большая часть мощности yield заключается в том, что выполнение в вашем методе или свойстве приостанавливается до тех пор, пока вызывающий код не выполнит итерацию следующего значения. Вот мой пример:
Использование ключевого слова yield (наряду с реализацией сопрограмм Caliburn.Micro Роба Айзенбурга) позволяет мне выразить асинхронный вызов веб-службы следующим образом:
public IEnumerable<IResult> HandleButtonClick() {
yield return Show.Busy();
var loginCall = new LoginResult(wsClient, Username, Password);
yield return loginCall;
this.IsLoggedIn = loginCall.Success;
yield return Show.NotBusy();
}
Для этого нужно включить мой BusyIndicator, вызвать метод Login в моей веб-службе, установить для моего флага IsLoggedIn возвращаемое значение, а затем снова отключить BusyIndicator.
Вот как это работает: IResult имеет метод Execute и событие Completed. Caliburn.Micro захватывает IEnumerator из вызова HandleButtonClick() и передает его в метод Coroutine.BeginExecute. Метод BeginExecute начинает перебирать IResults. Когда возвращается первый IResult, выполнение приостанавливается внутри HandleButtonClick(), и BeginExecute() присоединяет обработчик события к событию Completed и вызывает Execute(). IResult.Execute() может выполнять либо синхронную, либо асинхронную задачу и запускает событие Completed, когда оно выполнено.
LoginResult выглядит примерно так:
public LoginResult : IResult {
// Constructor to set private members...
public void Execute(ActionExecutionContext context) {
wsClient.LoginCompleted += (sender, e) => {
this.Success = e.Result;
Completed(this, new ResultCompletionEventArgs());
};
wsClient.Login(username, password);
}
public event EventHandler<ResultCompletionEventArgs> Completed = delegate { };
public bool Success { get; private set; }
}
Это может помочь настроить что-то вроде этого и пройти через выполнение, чтобы посмотреть, что происходит.
Надеюсь, это поможет кому-то! Я действительно любил исследовать различные способы, которыми можно использовать урожай.
Это может показаться странным предложением, но я научился использовать yield ключевое слово в C#, читая презентацию о генераторах в Python: http://www.dabeaz.com/generators/Generators.pdf Дэвида М. Бизли. Вам не нужно много знать Python, чтобы понять презентацию - я не знал. Я нашел, что это очень полезно объяснить не только как работают генераторы, но и почему вы должны заботиться.
Возврат доходности может быть очень мощным для алгоритмов, где вам нужно перебирать миллионы объектов. Рассмотрим следующий пример, где вам нужно рассчитать возможные поездки на rideshare. Сначала мы генерируем возможные поездки:
static IEnumerable<Trip> CreatePossibleTrips()
{
for (int i = 0; i < 1000000; i++)
{
yield return new Trip
{
Id = i.ToString(),
Driver = new Driver { Id = i.ToString() }
};
}
}
Затем повторяйте каждую поездку:
static void Main(string[] args)
{
foreach (var trip in CreatePossibleTrips(trips))
{
// possible trip is actually calculated only at this point, because of yield
if (IsTripGood(trip))
{
// match good trip
}
}
}
Если вы используете List вместо yield, вам потребуется выделить 1 миллион объектов в память (~190 МБ), и для этого простого примера потребуется ~1400 мс. Однако, если вы используете yield, вам не нужно помещать все эти временные объекты в память, и вы получите значительно более высокую скорость алгоритма: этот пример займет всего ~400 мс для запуска без использования памяти вообще.
Вот что говорит Крис Селлс об этих утверждениях на языке программирования C#;
Иногда я забываю, что yield return не совпадает с return, потому что код после yield return может быть выполнен. Например, код после первого возврата здесь никогда не может быть выполнен:
int F() { return 1; return 2; // Can never be executed }Напротив, код после первого возврата может быть выполнен:
IEnumerable<int> F() { yield return 1; yield return 2; // Can be executed }Это часто кусает меня в утверждении if:
IEnumerable<int> F() { if(...) { yield return 1; } // I mean this to be the only // thing returned yield return 2; // Oops! }В этих случаях полезно помнить, что возврат доходности не является "окончательным", как возврат.
Два куска кода действительно делают две разные вещи. Первая версия будет тянуть участников по мере необходимости. Вторая версия загрузит все результаты в память, прежде чем вы начнете что-либо делать с ней.
Там нет правильного или неправильного ответа на этот. Какой из них предпочтительнее, зависит только от ситуации. Например, если у вас есть ограничение по времени для выполнения запроса, и вам нужно сделать что-то сложное с результатами, вторая версия может быть предпочтительнее. Но остерегайтесь больших наборов результатов, особенно если вы запускаете этот код в 32-битном режиме. Я был укушен исключениями OutOfMemory несколько раз при выполнении этого метода.
Главное, что нужно иметь в виду, это: различия в эффективности. Таким образом, вы, вероятно, должны следовать тому, что делает ваш код проще, и изменять его только после профилирования.
У выхода есть два отличных применения
Это помогает обеспечить пользовательскую итерацию без создания временных коллекций. (загрузка всех данных и цикл)
Это помогает делать итерацию с учетом состояния. (потоковое)
Ниже приведено простое видео, которое я создал с полной демонстрацией, чтобы поддержать два вышеуказанных пункта.
Это своего рода помимо сути, но так как вопрос помечен как лучшие практики, я добавлю два своих цента. Для этого типа вещей я предпочитаю превратить его в свойство:
public static IEnumerable<Product> AllProducts
{
get {
using (AdventureWorksEntities db = new AdventureWorksEntities()) {
var products = from product in db.Product
select product;
return products;
}
}
}
Конечно, это немного больше, но код, который использует это, будет выглядеть намного чище:
prices = Whatever.AllProducts.Select (product => product.price);
против
prices = Whatever.GetAllProducts().Select (product => product.price);
Примечание: я бы не стал делать это для любых методов, которые могут занять некоторое время, чтобы выполнить свою работу.
Предполагая, что ваш класс LINQ продуктов использует аналогичный выход для перечисления / итерации, первая версия более эффективна, потому что она дает только одно значение каждый раз, когда повторяется.
Второй пример - преобразование перечислителя / итератора в список с помощью метода ToList(). Это означает, что он вручную перебирает все элементы в перечислителе, а затем возвращает плоский список.
А что по этому поводу?
public static IEnumerable<Product> GetAllProducts()
{
using (AdventureWorksEntities db = new AdventureWorksEntities())
{
var products = from product in db.Product
select product;
return products.ToList();
}
}
Я думаю, это намного чище. У меня нет VS2008 под рукой, чтобы проверить, хотя. В любом случае, если Products реализует IEnumerable (как кажется - он используется в операторе foreach), я бы вернул его напрямую.
Я бы использовал версию 2 кода в этом случае. Поскольку у вас есть полный список доступных продуктов, и это то, что ожидает "потребитель" этого вызова метода, потребуется отправить полную информацию обратно вызывающей стороне.
Если вызывающая сторона этого метода требует "одну" информацию за раз, и потребление следующей информации основывается на требовании, тогда было бы полезно использовать возвращение доходности, которое будет гарантировать, что команда выполнения будет возвращена вызывающей стороне, когда единица информации доступна.
Некоторые примеры, где можно использовать возвращение доходности:
- Сложный пошаговый расчет, при котором вызывающий ожидает данные шага за раз
- Пейджинг в графическом интерфейсе - когда пользователь может никогда не дойти до последней страницы, и на текущей странице необходимо раскрыть только часть информации
Чтобы ответить на ваши вопросы, я бы использовал версию 2.
Вернуть список напрямую. Выгоды:
- Это более понятно
-
Список можно использовать повторно.(итератор не)не совсем верно, спасибо Джон
Вы должны использовать итератор (yield) с того момента, когда вы думаете, что вам, вероятно, не придется перебирать весь путь до конца списка или когда у него нет конца. Например, клиентский вызов будет искать первый продукт, который удовлетворяет некоторому предикату, вы можете подумать об использовании итератора, хотя это надуманный пример, и, вероятно, есть более эффективные способы его выполнения. В принципе, если вы знаете заранее, что весь список нужно будет рассчитать, просто сделайте это заранее. Если вы думаете, что это не так, то подумайте об использовании версии итератора.
Ключевая фраза yield return используется для поддержки конечного автомата для конкретной коллекции. Везде, где CLR видит используемую ключевую фразу возврата-возврата, CLR реализует шаблон Enumerator для этого фрагмента кода. Этот тип реализации помогает разработчику из всех типов сантехники, которые в противном случае пришлось бы делать в отсутствие ключевого слова.
Предположим, что разработчик фильтрует некоторую коллекцию, выполняет итерацию по коллекции и затем извлекает эти объекты в какую-то новую коллекцию. Этот вид сантехники довольно однообразен.
Подробнее о ключевом слове здесь в этой статье.
Учитывая два точных фрагмента кода, я считаю, что версия 1 лучше, поскольку она может быть более эффективной. Допустим, существует много продуктов, и вызывающий абонент хочет преобразовать их в DTO.
var dtos = GetAllProducts().Select(ConvertToDto).ToList();
В версии 2 сначала будет создан список объектов Product, а затем еще один список объектов ProductDto. В версии 1 нет списка объектов Product, создается только список необходимых объектов ProductDto.
На мой взгляд, даже без преобразования у версии 2 есть проблема: список возвращается как IEnumerable. Вызывающий GetAllProducts() не знает, насколько дорого обходится перечисление результата. И если вызывающему абоненту необходимо выполнить итерацию более одного раза, он, вероятно, материализуется один раз с помощью ToList() (такие инструменты, как ReSharper, также предлагают это). В результате получается ненужная копия списка, уже созданного в GetAllProducts(). Поэтому, если следует использовать версию 2, возвращаемый тип должен быть List, а не IEnumerable.
Использование yield аналогично ключевому слову return, за исключением того, что оно возвращает генератор. И объект генератора будет проходить только один раз.
У выхода есть два преимущества:
- Вам не нужно читать эти значения дважды;
- Вы можете получить много дочерних узлов, но не обязательно помещать их все в память.
Есть еще одно четкое объяснение, может быть, вам поможет.