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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Понятно, что там где скорость нужна и нужно экономить десятки секунд ручная оптимизация нужна.
Но там где тратятся миллисекунды 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