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

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

Сценарий 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 ответа

Решение

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

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

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

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

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

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

И почему?

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

Источник

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

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

Источник

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

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

Источник

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

Пожалуйста, взгляните.

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

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

Источник
Другие вопросы по тегам