Force Linq не задерживает выполнение

На самом деле, это тот же вопрос, что и этот пост:

Как я могу убедиться, что мои запросы LINQ выполняются при вызове в моем DAL, а не с задержкой?

Но так как он не объяснил, почему он этого хочет, вопрос, похоже, прошел немного. Здесь моя аналогичная, но лучше объясненная проблема:

У меня есть несколько потоков в двух типах (игнорируя потоки пользовательского интерфейса на мгновение). Там тип потока данных "сбор данных" и тип потока "вычислений". Потоки сбора данных медленны. Там довольно много данных, которые нужно просеять из разных мест. Потоки вычислений сравнительно быстрые. Модель проектирования до этого момента заключается в том, чтобы отправлять потоки сбора данных, чтобы найти данные, и когда они будут полностью переданы данные для вычислений.

Когда я закодировал сбор данных в Linq, я запустил часть этой медленности обратно в мои потоки вычислений. Теперь есть элементы данных, которые полностью не разрешаются до тех пор, пока они не используются во время вычислений, и что проблема.

Я хочу заставить Linq завершить работу в данный момент (конец инструкции? конец метода?), пожалуйста, закончите, пропустите "вызов метода", чтобы я знал, что не буду платить за это позже, Добавление ".ToList()" в конец Linq 1. неудобно, и 2. чувствует себя как бокс, что-то, что скоро будет распаковано в другой поток.

Ответ 1

Вы не будете боксировать что-нибудь - вы буферизуете результаты.

Использование ToList() - это, в основном, путь, если вы действительно хотите данные. Если вы не будете готовы немедленно использовать данные, это должно быть где-то забуферировано, не так ли? Список - это просто удобный способ сделать это.

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

В вашем описании это несколько явно выражено:

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

Вызов ToList() в основном изменяет то, что вы возвращаете из "запроса, который может извлекать данные при запросе" на "самих данных, буферизованных в списке".

Ответ 2

Можете ли вы объяснить, почему. ToList не приемлем? Вы упомянули бокс и распаковку, но это совершенно не связанные темы.

Часть принудительного запроса LINQ для завершения по требованию требует сохранения результатов. В противном случае, чтобы снова увидеть результаты, вам придется повторно обрабатывать запрос..ToList эффективно достигает этого, сохраняя элементы в List<T>.

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

Ответ 3

В классе DataContext есть свойство LoadOptions, которое может помочь вам получить данные более охотно.

Иначе вы могли бы использовать несколько умных размещенных ToList().

Ответ 4

Я знаю, что эта ветка старая... в любом случае, смешно, что никто не упомянул. ToLast(). Я делаю что-то, где linq не намного больше, чем прославленный foreach, приводящий некоторые побочные эффекты, когда мне действительно не нужен результат запроса... поэтому я не хотел выделять более ложную память, чем необходимо.