Какова эффективность и производительность LINQ и лямбда-выражений в .Net?

Question

Я использую .Net 3.5 и VS 2008 более месяца. Как и большинство разработчиков .Net, я приобрел многолетний опыт работы в .Net 1.0 и 2.0 и VS 2005. Совсем недавно я обнаружил простоту и мощь выражений LINQ и Lambda, как и в моих недавних вопросах, таких как Найти предметв списке с помощью LINQ , Преобразование или отображение экземпляра класса в список другого с помощью Lambda или LINQ и Преобразование или сопоставление списка класса с другим списком класса с помощьюLambda или LINQ .

Я признаю, что Lambda и LINQ намного проще и удобнее для чтения, и они кажутся очень мощными. За кулисами компилятор .Net должен генерировать много кода для выполнения этих функций. Поэтому я немного не решаюсь перейти на новый синтаксис, так как я уже знаю «старый» способ достижения тех же результатов.

У меня вопрос об эффективности и производительности Lambda и LINQ. Может быть, лямбда-выражения в основном являются встроенными функциями, в этом случае я думаю, что лямбда должна быть в порядке. Как насчет LINQ?

Давайте ограничимся обсуждением LINQ-to-Objects LINQ-to-SQL (LINQ-to-SQL). Любые комментарии, сравнения и опыт?

Answer 1

Здесь нет ни одного единственного ответа, который будет здесь достаточен.

LINQ имеет много применений и множество реализаций, и, следовательно, имеет много последствий для эффективности вашего кода.

Как и для каждого фрагментаТехнологии, которые у нас под рукой, LINQ могут и будут злоупотреблять и злоупотреблять одинаково, и способность различать это и правильное использование зависит только от одной вещи: знания.

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

Вы должны проверить следующее:

• LINQ и как он использует методы и методы расширения для существующих типов коллекций
  • Как работает LINQ
  • Как внутренне работает LINQ (переполнение стека)
  • Как работает кодирование с помощью LINQ? Что происходит за кулисами?
• Чем отличаются LINQ-to-objects и LINQ-to-SQL
  • В чем разница между запросами LINQвыражения и методы расширения (переполнение стека)
• Альтернативы новому синтаксису LINQ, например, использование метода расширения .Where (...) для коллекций

И, как всегда, при рассмотрении вопросов эффективности единственный безопасный подход - это просто измерение. Создайте фрагмент кода, используя LINQ, который выполняет единственную задачу, знает, что-то, и создайте альтернативу, затем измерьте оба и попытайтесь улучшить. Гадание и предположение приведут только к плохим результатам.

Answer 2

Технически самый быстрый способ - это контролировать все мелочи самостоятельно. Вот некоторые тесты производительности . Обратите внимание, что ключевое слово foreach и конструкция ForEach LINQ идентично намного медленнее, чем просто использование for и написание процедурного кода.

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

Answer 3

Для запросов LINQ с «новым синтаксисом» сгенерированный IL (код) принципиально не отличается от вызова методов расширения, предоставляемых непосредственно через Enumerable и Queryable.

Answer 4

Не оптимизировать преждевременно. Используйте Linq и новые методы расширения свободно, если они улучшают читабельность и впоследствии профилируют ваше приложение.

В большинстве случаев разница между Linq и использованием циклов plain for вообще не актуальна. Улучшенная поддержка вашего кода должна стоить несколько мс. Linq может работать медленнее, потому что он работает на перечислителях, которые реализованы как конечные автоматы. Так что обычные (...) циклы будут быстрее.

Я бы порекомендовал последовать совету Лассе В. Карлсена и добавить http://www.davesquared.net/2009/07/enumerables-linq-and-speed.html в его список ссылок.

Answer 5

Нет разницы в производительности между запросами LINQ и лямбда-выражениями.

Вы должны полностью понять, как работает функция LINQ (и Lambda, и запросы LINQ) в .Net, прежде чем вы будете рассматривать проблемы с производительностью.

По сути, вы можете работать с любым из запросов LINQ иЛямбда-выражения ..

LINQ Queries

1. Это читаемый запрос высокого уровня.

2. Itпреобразуется в эквивалентные лямбда-выражения, а лямбда-выражения добавляются в виде узлов в дерево выражений. Дерево выражений, которое составляет структуру лямбда-выражений. Это делается компилятором.

3. Поставщик запросов просматривает выражения (добавляются в виде узлов в дереве выражений) и создает эквивалентные операторы SQL-запросов, таким образом эквивалентный SQL-запрос, сформированный во время выполнения.

4. Тип возврата: набор результатов (IEnumerable).

Лямбда-выражения

1. Это набор выражений / операторов, создающий делегат / дерево выражений. Он может быть передан функции в качестве аргумента.

2. Он поддерживает все методы LINQ, такие как запросы LINQ. (Where, Select, Count, Sum и т. Д.)

3. Формируется дерево выражений, которое создает структуру лямбда-выражений. Это делается компилятором.

4. Поставщик запросов просматривает выражения (дерево выражений) и создает эквивалентный SQL-запрос во время выполнения.

5. Тип возвращаемого значения:Delagate / Expression Tree

Что лучше?

Вы можете понять LINQ (Queries, Lambda) Если вы посмотрите на вышеупомянутые пункты.

Преимущество запроса LINQ - он доступен для чтения.

Преимущество лямбды

1. Преимущество лямбды будет заключаться в том, что она создает делегата и с помощьюВы можете просто передать входные параметры и получить результат для разных входных параметров. Вам также не нужно писать разные запросы для разных критериев.

2. Вы можете создать динамический запрос с помощью Lambdaвыражения и деревья выражений.

3. Вы можете использовать лямбда-выражения, если хотите передать результат оператора (ов) в метод в качестве аргумента.

4. выражения короче.

Так что лямбда-выражение лучше всего подходит для разработки над запросами LINQ.

Answer 6

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