home.social

#linq — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #linq, aggregated by home.social.

fetched live
  1. Бенчмаркая LINQ: подстава с OrderBy — одно условие и полная сортировка

    Одни вызовы после OrderBy проходят набор один раз, другие приводят к полной сортировке. По коду разницы не видно. Давайте проверим счётчиком обращений к компаратору — на четырёх машинах и четырёх рантаймах.

    habr.com/ru/articles/1073310/

    #LINQ #OrderBy #First #сортировка #BenchmarkDotNet #производительность #NET_11 #компаратор #оптимизация

  2. Бенчмаркая пагинацию: Where перед Skip — и метод в 1323 раза медленнее

    Один Where в начале запроса — и метод медленнее в тысячу раз. Причём чем дальше страница, тем хуже: на первой разница полтора раза, на тысячной — почти в 1000. Дело не в самой фильтрации. Всё решает то, что LINQ делает под капотом.

    habr.com/ru/articles/1071514/

    #LINQ #пагинация #Skip #Take #Where #BenchmarkDotNet #NET_10 #производительность #бенчмарк #UseSizeOptimizedLinq

  3. Бенчмаркая Enumerable.Chunk: почему батчей меньше, а проход до ×2,7 дольше

    Chunk делит коллекцию на массивы — одна строка кода. Но есть размер чанка, после которого он замедляется в разы при тех же данных и той же памяти. А на массиве и на List<int> внутри разный код, и в самой строке этого не видно.

    habr.com/ru/articles/1067238/

    #EnumerableChunk #LINQ #куча_больших_объектов #LOH #сборщик_мусора #чанки #батчинг #BenchmarkDotNet #NET_10 #аллокации

  4. Бенчмаркая ZLinq: один IEnumerable в сигнатуре — и .NET 10 быстрее библиотеки в 3,9 раза

    ZLinq — замена LINQ без аллокаций. На .NET 8 и .NET 9 время одинаковое. На .NET 10 иначе: массив тот же, но если параметр объявлен как IEnumerable, foreach перебирает его в 2,58–3,89 раза быстрее ZLinq. Причина видна в машинном коде, память замерена отдельно.

    habr.com/ru/articles/1065192/

    #ZLinq #LINQ #IEnumerable #аллокации #бенчмарк #BenchmarkDotNet #производительность #NET_10 #JIT #дизассемблер

  5. Ленивый LINQ: разбираем yield и ленивые вычисления по кирпичикам. Часть 2

    В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось. Во второй части переходим к «тяжёлой артиллерии» — OrderBy , GroupBy и Join . Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно? После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.

    habr.com/ru/articles/1062802/

    #net #linq #yield #c# #компилятор #итераторы #ленивые_вычисления #отложенное_выполнение #ienumerable #deffered_execution

  6. Ленивый LINQ: разбираем yield и ленивые вычисления по кирпичикам

    Каждый C#‑разработчик писал numbers.Where(x => x > 10).Select(x => x * 2) — и удивлялся, узнав, что эта строчка ничего не вычисляет. Цепочка спит, пока мы не начнём перебирать результат. За этим стоит конкретный механизм — отложенные вычисления, а в его основе лежит обычная фича языка: yield . Разбираем, как устроены ленивые методы LINQ изнутри — от ручной реализации Where без yield до того, во что этот yield разворачивается компилятором. А вы точно знаете, что происходит под капотом каждый раз, когда пишете .Where(...).Select(...) ? К статье приложен репозиторий с полной реализацией.

    habr.com/ru/articles/1061386/

    #C# #LINQ #yield #NET #отложенные_вычисления #deffered_execution #итераторы #IEnumerable #ленивые_вычисления #компилятор

  7. Бенчмаркая регресс LINQ: обещали −19%, на четырёх машинах намерил +31%

    Уважаемые читатели, в этой статье я хочу рассказать о проверке обещанного регресса LINQ в .NET 10 — и представить свои выводы. В dotnet/runtime с лета висит issue #117717 : после перехода на .NET 10 метод с First(предикат) просел к девятке — у автора issue на Intel 13-го поколения до 19%, у Энди Эйерса из JIT-команды на Zen 4 порядка 10%. Причину команда назвала сама: связка PGO и инлайнинга, делегат предиката перестал инлайниться. Решение тоже озвучили: в десятке чинить не будем — сломаем другое, переносим в .NET 11. Был частичный фикс ( PR #117816 ), после которого issue переоткрыли как #119425 . Десятка при этом LTS, и в комментах закономерный вопрос: обновляться на десятку или ждать одиннадцатую.

    habr.com/ru/articles/1060518/

    #benchmarkdotnet #linq #first #регресс #net_10 #jit #pgo #инлайнинг #производительность #osr

  8. Бенчмаркая Sum: ускорил циклом — замедлил в ×4,7

    Уважаемые читатели, в этой статье я хочу рассказать о том, что происходит внутри values.Sum() в современном .NET — там нашлись векторные инструкции, контроль переполнения и список процессоров, которым рантайм намеренно ограничивает ширину вектора, — и представить свои выводы. В прошлых статьях серии самописные циклы уже проигрывали BCL в поиске по строке , JIT сам выкидывал проверки границ , а foreach прятал аллокации . Тут случай интереснее: values.Sum() — это LINQ, который при оптимизации первым делом меняют на цикл.

    habr.com/ru/articles/1060470/

    #benchmarkdotnet #linq #sum #simd #avx512 #векторизация #производительность #jit #ryujit #overflowexception

  9. redb — типизированное хранилище для .NET поверх Postgres/MSSQL: без миграций, без Include, с полным LINQ

    Типизированное хранилище для .NET поверх Postgres и MSSQL. C#-класс как схема — без миграций, без Include, с полным LINQ. Работает в проде. LoadAsync вместо 40 Include →

    habr.com/ru/articles/1042058/

    #LINQ #миграции #EF_Core #object_store #redb #opensource #PostgreSQL #MSSQL #NET

  10. The fact that I could express the whole search algorithm over desired world states in my #versu re-engineering in a single, concise #LINQ query is both fantastic and terrifying.

  11. glinq: LINQ для Go с ленивыми вычислениями

    Привет, Хабр! Я бэкенд-разработчик в спортивном медиа Спортс”. В этой статье расскажу о glinq – LINQ-подобном API для работы с коллекциями в Go. После появления дженериков в Go 1.18 стало возможным реализовать type-safe функциональные операции без рефлексии и дорогостоящих приведений типов.

    habr.com/ru/articles/973828/

    #go #golang #linq

  12. Создаёте списки в C#? Ну тогда у вас могут быть проблемы

    Мы все привыкли писать new List<int> { 1, 2, 3, 4 } или new int[] { 1, 2, 3, 4} , чтобы инициализировать коллекции какими-то значениями. Синтаксически это выглядит похоже, но поведение отличается, и вам следует быть осторожными, если вы заботитесь о производительности.

    habr.com/ru/companies/skbkontu

    #net #linq #c# #array #list

  13. Удаляем пробелы из строки

    Недавно мы разбирали популярную задачу — проверяли строку на наличие цифр . Еще одна популярная задача при работе со строками — удалить из них пробельные символы. Можно представить, что нам нужно очистить пользовательский ввод: удалить пробелы вначале и конце строк в имени или удалить пробелы из телефонного номера. .NET предоставляет нам несколько возможностей для решения этой задачи, давайте рассмотрим самые популярные и попробуем найти наиболее эффективные. Заодно проверим, какие изменения произошли в новой версии .NET 10.

    habr.com/ru/companies/skbkontu

    #net #linq #regex #c# #string