Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

I>>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз.

I>>>Речь то не идет о том, плох linq или хорош, а о том, когда и где хорошо справляется, а когда и где есть вещи получше.

I>>>Я уверен, ты не понимаешь фразу выше. Ну не понимаешь и всё. Особенность у тебя такая. Попроси может кого, что бы объяснили, что это значит с т.з. русского языка.
S>> Вот напиши и покажи.
S>>И обоснуй минус!

I>Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield
Все последнее сообщение. Ты так и не понял смысл Linq для коллекций.
1. Суть прежде всего в читаемости кода!
2. Быть достаточно производительныим и !!! ленивым и жрали по минимуму памяти
3. Можно оптимизировать запросы если все находятся в одном месте по типу Linq Rewrite
используя тот же Source генератор. По сути это аналог IQueriable на этапе компиляции.
4. Там где нужно инамически создавать цепочки запросов. Тут просто вручную невозможно оптимизировать. Слишком много вариантов.

Понятно, что там где скорость нужна и нужно экономить десятки секунд ручная оптимизация нужна.
Но там где тратятся миллисекунды Linq прекрасно работает даже если это будет в 4 раза дольше чем все в ручную, потому что например запись в БД,
отображение данных или ответ на Htth запрос с последующей десериализацие данных намного дольше чем работа итераторов.

А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.

Ну и делать расширения например для создания енумераторов над деревьями, содержимым файлов итд, где затраты на энумераторы ничтожны по сравнению с обходом содержимого.
Например Linq To XML https://habr.com/ru/post/24673/
https://referencesource.microsoft.com/#System.Xml.Linq/System/Xml/Linq/XLinq.cs,3354dac0913e417b

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Serginio1, Вы писали:

I>>>Я могу написать другой тест, который провалит замеры против массива во сколько угодно раз.

I>>>Речь то не идет о том, плох linq или хорош, а о том, когда и где хорошо справляется, а когда и где есть вещи получше.

I>>>Я уверен, ты не понимаешь фразу выше. Ну не понимаешь и всё. Особенность у тебя такая. Попроси может кого, что бы объяснили, что это значит с т.з. русского языка.
S>> Вот напиши и покажи.
S>>И обоснуй минус!

I>Все что надо, уже сделано. ты сам показал тесты, где прямая итерация оказывается быстрее косвенной через yield
Все последнее сообщение. Ты так и не понял смысл Linq для коллекций.
1. Суть прежде всего в читаемости кода!
2. Быть достаточно производительныим и !!! ленивым и жрали по минимуму памяти
то есть вычиления идут с права на лево, без создания итераторов на List (при этом вычисления пойдут с лева направо, так как для получения итератора на уровне Lis
нужно вызвать все MoveNext у родительского итератора)
3. Можно оптимизировать запросы если все находятся в одном месте по типу Linq Rewrite
используя тот же Source генератор. По сути это аналог IQueryable,но на этапе компиляции и можно в нем отлаживать код!!
4. Там где нужно динамически создавать цепочки запросов. Тут просто вручную невозможно оптимизировать. Слишком много вариантов.

Понятно, что там где скорость нужна и нужно экономить секунды или десятки секунд ручная оптимизация нужна.
Но там где тратятся миллисекунды Linq прекрасно работает даже если это будет в 4 раза дольше чем все в ручную, потому что например запись в БД,
отображение данных или ответ на Htth запрос с последующей десериализацие данных намного дольше чем работа итераторов.

А вот читаемость кода значительно важнее. Особенно кода количество кода измеряется мегабайтами. Скорость кодирования и разбираться с чужим своим кодом намного важнее.

Ну и делать расширения например для создания енумераторов над деревьями, содержимым файлов итд, где затраты на энумераторы ничтожны по сравнению с обходом содержимого.
Например Linq To XML https://habr.com/ru/post/24673/
https://referencesource.microsoft.com/#System.Xml.Linq/System/Xml/Linq/XLinq.cs,3354dac0913e417b