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

_>>Ну как же. Напомню, что в той нашей задачке происходила фильтрация по условию количества элементов внутренней коллекции в предыдущем элементе (который ты перевёл в текущий с помощью копирования). Т.е. при таком подходе у тебя на верхнем уровне получается не пара значений, а пара коллекций, которые ты соответственно обрабатываешь циклами.
S>А, я понял. Хочется наиграть на том, что мы типа итерируемся по коллекции, и сэкономить проход цикла. Ну, идея сама по себе интересная, хотя насколько драматичным будет выигрыш в производительности — вопрос открытый.
S>То есть понятно, что по факту linq проиграет, но не из-за семантики, а из-за того, что оптимизатор JIT-а сосёт.

Ну linq то тут в любом случае проиграл бы, просто из-за тормознутости сопрограмм, необходимости копирования и т.п. Это в любой задаче из данной области. А вот в данной конкретной задаче (где у нас вложенные коллекции и условие по предыдущему элементу) появился ещё и дополнительный алгоритмический провал.

S>А в том случае, если мы вычисляем одну и ту же f() от предыдущей и следующей коллекции, мы по-прежнему можем сэкономить на проходе цикла, сделав PairScan по результатам вычисления, а не по самой коллекции.

Конечно. Но если ты будешь вставлять условия фильтрации грубо говоря не в блоке where, а внутри некой своей дополнительной функции, генерирующей пары, то это будет по сути уже не linq, а тот же самый императивный код.