LINQ быстрее или просто удобнее? - PullRequest
Новая
       1

LINQ быстрее или просто удобнее?

3 голосов
/ 08 декабря 2010

Какой из этих сценариев будет быстрее?

Сценарий 1: 

foreach (var file in directory.GetFiles())
{
    if (file.Extension.ToLower() != ".txt" &&
        file.Extension.ToLower() != ".bin")
        continue;

    // Do something cool.
}

Сценарий 2: 

var files = from file in directory.GetFiles()
                where file.Extension.ToLower() == ".txt" ||
                      file.Extension.ToLower() == ".bin"
                select file;

foreach (var file in files)
{
     // Do something cool.
}

Я знаю, что они логически одинаковыотсроченного исполнения, но что будет быстрее?И почему?

Ответы [ 4 ]

6 голосов
/ 08 декабря 2010

Ускорение обычно не является проблемой само по себе, особенно в сценарии, подобном этому, где не будет существенной разницы в производительности (и в целом, если код не является узким местом, это просто не имеет значения).Вопрос в том, что является более читабельным и более четко выражает намерение кода.

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

Является ли LINQ быстрее или просто удобнее?

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

Я знаю, что они логически одинаковы из-за отложенного выполнения, но что будет быстрее?

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

И почему?

Потому что LINQдобавляет немного накладных расходов.Но компромисс значительно более понятный и более понятный код.Это огромная победа по сравнению с обычно несущественной потерей производительности.

2 голосов
/ 08 декабря 2010

Было бы быстрее сделать GetFiles("*.txt") и GetFile("*.bin"), если каталог содержит много файлов или находится на сетевом диске.

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

1 голос
/ 08 декабря 2010

Linq не быстрее и не совсем удобен. Скорее, Linq вытягивает функции высшего порядка Fold , Map и Filter в .NET (с разными именами). Эти функции ценны, потому что они позволяют нам DRY - наш код. Каждый раз, когда вы настраиваете итерацию со вторичной коллекцией или результатом, вы открываете себя для ошибки. Linq позволяет вам сосредоточиться на том, что происходит внутри итерации, и чувствовать себя достаточно уверенно, что итерационная механика не содержит ошибок.

Это не значит, что Linq строго медленнее, чем ручная итерация. Как уже упоминали другие, вам придется тестировать в каждом конкретном случае.

0 голосов
/ 08 декабря 2010

Я написал статью о Code Project, которая сравнивала linq и хранимые процедуры, а также использовала скомпилированный linq.

Пожалуйста, посмотрите.

http://www.codeproject.com/KB/cs/linqsql2.aspx

Я понимаю, что вы смотрите на локальный анализ файлов, статья даст вам некоторое представление о том, что происходит и что такое linqделает за кулисами.

...