Комментарии 26
Оптимизация прикольная, но как-то не очень интересная. В реальном коде Min на массиве напрямую вызываться, скорее всего, не будет — между ними будут хотя бы Select и Where.
Вот если бы они общий случай ускорить умудрились...
Linq сложно читается... what?
И уж точно проще регулярных выражений :)
Да нет, все верно.
Linq (или например реактивные расширения) очень плотные, обладают специфической логикой и не очень добры к инструментам пояснения, типа нейминга.
Например можно добавить GroupBy(itemsGroup => Condition(itemsGrout)), но логический смысл группировки будет раскрыт хуже, чем если бы мы писали в обычном процедурном стиле с временными переменными.
Исторически так сложилось, что LINQ взыскал сомнительную репутацию за его слабую производительность. LINQ медленный, аллоцирует память, сложно читается, поэтому обычно его используют как инструмент запросов к БД и то, зачастую сложные запросы легче написать на SQL. Даже на собеседованиях джунов просят не использовать LINQ в алгоритмах.
Вот честно, первый раз слышу такие претензии. Что касается «медленный и аллоцирует память» — ну если делать lazy цепочки над IEnumerable ничего там аллоцироваться не будет и медленно работать тоже. По поводу сложно читается — во всех наших командах мы как раз можем пренебречь потерями в производительности ради декларативности Linq, которая плюс-минус понятна всем. Про базу данных — ну наверное, если можно писать запросы на Linq (в EF или где там еще), то база это позволяет, а если нужен перфоманс — то велком в plain SQL или прости господи процедуры и иже с ними.
Вот про джунов согласен — понятное дело, что если на собеседовании просят, например, отсортировать коллекцию, то .Sort() это слишком толстый лайфхак)
То есть на собеседовании вы просите джуна отсортировать массив? А каким алгоритмом? Если пузырьком, то это вообще бесполезно. Максимум, надо знать О нотацию и основную идею алгоритма. А если вы просите написать qsort, то это вообще нонсенс. Даже Яндекс (и всё, что выше за границей) не просят писать алгоритмы сложнее бинарного поиска, там задачи на подумать. Возможно, у вас компания, которая занимается оптимизацией алгоритмов сортировки, тогда я могу понять такой вопрос, иначе он бесполезен
Также появились новые методы TryGetNonEnumeratedCount(), чтобы не проходиться по коллекции для получения Count
Пример дичайшего легаси. А все потому, что программисты использовали count для выполнения побочных эффектов. И теперь нельзя ускорить этот метод, не сломав кучу пользовательского кода.
Прошу прощения, а для чего ещё может использоваться Count?
Для подсчёта количества, как бы.
Да нет, я не об этом, автор коментария говорит о побочных эффекта. Мне вот стали интересны именно они.
Ну вот смотрите:
var hashSet = new HashSet<Foo>();
foos.Count(hashSet.Add);Это ещё более-менее (скорее менее, чем более) нормальный способ, ведь подсчитать число удовлетворяющих предикату объектов невозможно без выполнения этого предиката. Но иногда делали и вот так:
var list = new List<Bar>();
foos.Select(foo => {
list.Add(foo.Bar);
return foo;
}).Count();Вот это уже абсолютно ненормальный способ, ведь селектор тут вообще исполнять никто не обязан. Но нет, были те кто считал это отличной заменой циклу foreach, ведь они совершенно точно знали, что внутри Count есть именно такой цикл! А теперь уже Microsoft не могут этот цикл убрать из Count…
Вы не любите кошек? Да вы просто их готовить не умеете.
Перед тем как чего-то написать ан LINQ я довольно долго писал и оптимизировал SQL запросы. По началу пришлось смотреть что в итоге LINQ отправляет серверу и от чего это зависит, оказалось что можно таки выйти на любой оптимальный SQL запрос используя синтаксис LINQ, и мне уже не хотелось писать внутри шарпового кода голые SQL.
Может Вы путаете LINQ (ORM) с Linq2DB (типизированный SQL)?
Ну конкретно мой комментарий конечно относится к работе с БД, а не просто с любыми коллекциями в памяти, да и в статье вроде как LINQ в контексте рядом с SQL. Хотя вот так сразу не вспомню сценария когда коллекция рождалась бы не из БД и с ней нужно было какие-то операции с большим объемом провернуть.
Много же примеров Linq2: XML, CSV и т.д.
Да и само понятие большое тоже растяжимое думаю, в каком-то кейсе 1000 штук много, в каком-то сотни миллионов не очень много.
Так я об этом и спросил. Если Linq сначала делает SELECT, предоставляя доступ к данным коду на клиенте, а потом INSERT ... VALUES или SqlBulkCopy, то Linq2DB ориентирована на [WITH ...] INSERT/MERGE ... FROM, когда клиенту данные могут вообще не пересылаться.
Парадигма разная. Первая - ORM, а вторая - синтаксический сахар для написания SQL в C# и берущая на себя проблемы различия синтаксиса в разных СУБД.
Фичи, конечно, крутые, и производительность радует, но почему бы не указать в начале поста источник, который автор решил перевести, и указать, что этот пост является переводом?
Сумачечая производительность LINQ в .Net7