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

S> да если я напишу свое расширение

S>

S>public static IEnumerable<T> AlternateElements<T>(this IEnumerable<T> source)
S>{
S>    int i = 0;
S>    foreach (var element in source)
S>    {
S>        if (i % 2 == 0)
S>        {
S>            yield return element;
S>        }
S>        i++;
S>    }
S>}
S>

S> То как видишь никаких тормозов на лямбдах нет

Вспоминаем, про что была речь

расходы yield и всякие лябмды равны

Выделенное ты упустил. А между тем yeild съест намного больше, чем if и %

То есть, осталось показать, как обнулить расходы и на yield. Без переписывания, как это теоретически может сделать компилер или джит, не выйдет.

S> Вообще то сказано было про то, что не будет лишних циклов из за ленивости. Но ты начал про тормоза лямбд. Про оптимизацию лямбд я тебе пишу но ты не читаешь. Ты ухватил только

Глаза раскрой — yield и лямбды.

S>"По этому мы можем объединять Where без потери производительности"

Ога.

S> Тогда прошу прощения. Сказано было в контексте лишних циклов. То есть если бы не ленивые вычисления, то были бы лишние циклы.

Ленивость можно сделать и без linq. И точно так же расходов будет меньше, как раз на этот самый yield.

И точно так же это проявится на большом количестве запросов. Загрузка процессора увеличится во столько раз, во сколько yield превышает твои if и %

I>>В дженериках интерфейсы и делегаты? Ты бы яснее мысли выражал.
S> Для сортровок и прочих обобщенных действий передаются для каждого типа интерфейсы или делегаты

И что с того?

S>"По этому мы можем объединять Where без потери производительности на лишние циклы"
S> Нет, но она значительно меньше если писать расширения без yield, потому что придется вычислять слева направо с кучей лишних циклов.

Не недо никаких лишних циклов. Ты руками то пробовал ленивость реализовывать?

S>Но на MoveNext ты все равно будешь тратиться. Единственный минус как тут правильно заметил Ночной Смотрящий это создание экземпляров классов итераторов при небольшом количестве элементов

Именно. MoveNext, издержки из за использования интерфейса и забрасываем гц мелкими объектами. Ты точно уверен, что гц выдержит любое количество таких объектов?

I>>По твоему, проблемы нет, потому есть её решение ? Если надо изыскивать особые комбинаторы, это значит, что просто так само работать не будет.
S>Если есть проблема которую можно решить через раширение то почему бы и нет?

Итого — проблема то есть.

I>>Еще одно решение для проблемы которой нет. Ты сам то понял, что показываешь? На кой ляд этот Рослин, если издержки yield равны нулю?
S> Главная фишка roslyn-linq-rewrite не yield а инлайнинг лямбд. Кстати например во многих сценариях yield удобнее так как не выделяет лишнюю память

Вот-вот. Покажи как от yield избавиться.

I>> Процитируй, где именно я призываю отказаться от linq ?

S>Ну ты же пишешь про тормоза везде и во всем но при этом отметаешь любые оптимизации.

Я пишу о том, что пенальти на yield есть всегда. Странно с этим спорить. Стоимость итерации вполне осязаема.
Пенальти и тормоза это разные вещи.