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

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

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

I>>Выделенное ты упустил. А между тем yeild съест намного больше, чем if и %
S> С чего бы. Это IEnumerable. Да в большинстве случаев это может выступать и массив и компилятор может развернуть цикл.
S>Но при работе ты так же и будешь вызывать MoveNext. yield просто оборачивает все в класс

Ты просил показить тебе твоё же отрицание — вот оно. Правда, здесь ты идешь дальше, и отрицаешь даже своё отрицание MoveNext, это вызов метода, switch, пара лишних присваиваний и взятие Current и некоторая мелочовка.
Это не сильно большие издержки в абсолютных числах. При этом в числодробилках даже такая мелочь может съедать слишком много.

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

А вот здесь стоит вспомнить, что быстрее всего итерироваться по массиву это через прямой доступ по индексу.

I>>Глаза раскрой — yield и лямбды.
S> Самому то не смешно. Ну я тебе кучу примеров привел где можно обходиться в итоге и без лямбд, а ншудв наоборот только ускоряет работу ибо не выделяет лишней памяти.
S>Сам раскрой и посмотри примеры. Я чего зря их ищу и тебе показываю. Ты же ничего даже не предоставил, что и насколько тормозит и стоит ли вообще на этом замарачиваться.

Ты в основном отрицаешь. Смотри выше.

I>>Итого — проблема то есть.
S> Она у тебя в голове. Ибо все пользуются Linq и мало у кого он является лимитирующей стадией.

Все да не все. Вопрос в том, что у тебя за вычисления. Если вычисление свойства делается за милисекунды, то конечно издержки linq будут равны нулю на таком фоне. Вероятно ты замерял перформанс именно в таком вот контексте.