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

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

S>> Я говорил, про то, что к списку того, что Linq , при кажущейся простоте, потребовал: нужно добавить yield. Ты с этим не согласен?

I>Я прямо процитировал с чем не согласен: "По этому мы можем объединять Where без потери производительности"

I>Ты забыл эту часть своего утверждения?
Но это было сказано в контексе ленивых вычислений, что итерация основного инумератора будет всего одна!
Ты с этим не согласен?
S>>Но часто нужно склеивать запросы передавая их в методы итд. Да жертвуем скоростью на выполнение лямбд, но если лямбда выполняет не действия над int
S>>То потери в производительности значительно меньше 2х

I>А ты сравнивал показания профайлера? Я вот взял да сравнил и выяснил, что для энергичных вычислений Linq даёт существенное замедление.
I>Для ленивых вычислений собственно ровно то же, но тут дело в отсутствии альтернативы. Или много сложного ручного кода, или короткий вариант на Linq
I>Тем не менее, пенальти никуда не девается.

Я уже лет двадцать сравниваю. Те же сортировки и прочие лабуду где используются дженерики без инлайнинга.
По твоему нужно отказаться и от дженериков?
Да и хрен с ним с этими пенальти. Важно скорость кодирования и легкость понимания кода.
S>>Сначала C# ники встретили Linq настороженно, но потом удобство перевысили потери в производительности

I>Да, я помню форматтер кода от джетбрейнс в решарпере на linq Который тормозил и мог сожрать всю память.

Во многих случаях просто невозможно без Linq. Но и в том же Linq ты можешь использовать расширения, где можно инлайнить нужный компаратор.
Там всего то будет 2 сточки кода с yield
И при этом все равно будет удобнее чем ручная реализация цепочки отборов, сортировок. Да на 1-2 проблем нет, но на 5 уже код нечитаемый
И в реалиях нужно применять динамически фильтры, соединения
Ну а сжирал память уж точно не из-за Linq.