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

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

I>>>>>То есть, x[0] оказывается медленее чем x.First() который унутре все равно вызовет x[0]
S>>>>Нет вывод в том, что ты должен вернуть енумератор на котором вызовется First().

I>>>А зачем мне вообще создавать энумератор ради взятия первого элемента?
S>>Там длинная цепочка Where, Select join итд может быть

I>Разумеется, если у тебя все завязано на линк, то иначе никак.
I>Если цель — убрать узкое место, то можно просто напросто другой алгоритм взять или даже вычислительную модель поменять.
I>А у тебя, похоже, нужно только за линк держаться, не дай бог отступить ради оптимизации

Ну вот где я это писал? Я на самом деле линк не часто использую, но там где он более выразителен, я плевал на экономию пару миллисекунд.
А вот по твоим словам нужно выжимать все до остатка. Тогда на голый С

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

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

S>>Ну не в 1000 раз!! Та затраты на MoveNext и Current есть. Но это порядка 3 секунд на миллиард!!

I>Если разница 8 раз, очевидно, что вычисления в один час будут идти 8 часов.
Ну ты представляешь какой это объем данных? Там на доступ памяти вне кэша затраты будут больше.
Миллиард в секунду. 8*60*60= 38 800 миллиардов итераций!! Ты там что итерируешьто?
S>>Реальные коллекции не достигают и миллиона. А это миллисекунды.

I>Коллекции — нет, а вот итерации — да.
Это как?
I>>>В таком случаяъ ты можешь получить какое угодно замедление.
Приведи примеры. Еще раз Where можно объединять
S>> В честь чего? Твои теории пока никак не подтверждены практикой.

I>Высокая стоимость. Потому нужно при возможности экспозить IList, тогда стандартный First обратится по индексу.
Ну на самом то деле если ты смотрел исходники Linq то там разные итераторы в том числе для Ilist array где доступ идет по индексу.

I>>>Обычно — да. Но не всегда. Если весь твой код плотно завязан на linq, и это, скажем, in-memory процессинг, то ты всего то работаешь в разы медленнее Это не проблема, пока не станет узким местом. Вопрос в том, как это узкое место устранять.
S>> Это станет узким местом при данных порядка миллиарда!! Все остальное это миллисекунды Которые и ловить не стоит.

I>Одна из моих оптимизаций сократила процессинг с 6 часов, до 6 минут. Небольшое кеширование добавил.
I>Всего на оптимизации потратил год с небольшой командой.
I>Масштабы понятны?

Ну вот у меня такие задачи были на 1С. Да кэширование и прочая лабуда. Но главное правильно составить запросы.


I>>>Например, репортинг я весь перевел на IEnumerable<Е> и Linq. А вот в рендеринге вычистил даже намёки на IEnumerable.
I>>>С другой стороны, в часто используемых коллекциях я вообще все перевел на массивы и получил огромный бенефит.
S>>Огромный ты не получишь. Максимум в 10 раз но и объемы у тебя должны быть огроменными. Ну и можно всегда использовать Linq Rewrite

I>Я уже озвучил бенефиты. От 10 до 10000 раз. Это после года работы над проектом.
I>Объемы огроменные. Не bigdata, но много всякого было.
38 800 миллиардов итераций!! Не ну можно конечно пузырьковую сортировку применять.
Когда ты говоришь о объемах где заметны MoveNext и Current даже bigdata становится мизерной

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

I>>Если разница 8 раз, очевидно, что вычисления в один час будут идти 8 часов.
S>Ну ты представляешь какой это объем данных? Там на доступ памяти вне кэша затраты будут больше.

Мне не надо это представлять — меня был именно такой проект.
С кешем очень интересно — твой вырожденый кейс, который ты замерил, попадает в идеальные условия с тз. кеша.
В реальности массив структур дает хорошее попадание в кеш. А вот linq обеспечивает кучу промахов.

S>Миллиард в секунду. 8*60*60= 38 800 миллиардов итераций!! Ты там что итерируешьто?

В принципе, не сильно то и сложные вычисления на средних объемах данных, просто много итераций.

I>>Коллекции — нет, а вот итерации — да.
S> Это как?

Например, коллекция может быть одна, а проходить по ней можем сотню раз, для разных целей, или рекусивно, или еще как

I>>>>В таком случаяъ ты можешь получить какое угодно замедление.
S>Приведи примеры. Еще раз Where можно объединять

Уже приводил. Не "можно" а "нужно", а часто "обязательно", иначе просядет из за yield до уровня Python.

I>>Высокая стоимость. Потому нужно при возможности экспозить IList, тогда стандартный First обратится по индексу.
S>Ну на самом то деле если ты смотрел исходники Linq то там разные итераторы в том числе для Ilist array где доступ идет по индексу.

Ты адекватен? Я именно это тебе и говорю. Потому и нужно выставить этот IList наружу. А раз так, то он всё равно у нас есть, а следовательно твои аргументы "с yield нам список не нужен" отменяются
Если нет этого интерфейса — надо выставить. Тогда ElementAt, First, Last итд ускоряются сами собой. Только тогда x[0] будет почти эквивалентным x.First(). Почти — это значит, что для критических путей можно и это убрать.

I>>Одна из моих оптимизаций сократила процессинг с 6 часов, до 6 минут. Небольшое кеширование добавил.
I>>Всего на оптимизации потратил год с небольшой командой.
I>>Масштабы понятны?

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

"Правильно составить запросы" в лучшем случае даст тебе те самые 2 ... 8.7 отставания, если у тебя нету никаких многослойных композиций.

I>>Я уже озвучил бенефиты. От 10 до 10000 раз. Это после года работы над проектом.
I>>Объемы огроменные. Не bigdata, но много всякого было.
S>38 800 миллиардов итераций!! Не ну можно конечно пузырьковую сортировку применять.

И что тебя смущает? Некоторые плагины были втч на С++ именно из-за этой особенности.

S>Когда ты говоришь о объемах где заметны MoveNext и Current даже bigdata становится мизерной

1.5 ... 8.7 раза будут заметны всегда. Если у тебя процессинг с 1мс стал 2мс, то пропускная способность уменьшилась с 1000 запросов до 500.
Например, для облака это значит, что тебе надо платить вдвое больше при том же результате.

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

I>>А у тебя, похоже, нужно только за линк держаться, не дай бог отступить ради оптимизации

S> Ну вот где я это писал? Я на самом деле линк не часто использую, но там где он более выразителен, я плевал на экономию пару миллисекунд.

Элементрарно — я пишу про узкое место, а ты тут же сунешь контр-аргумент "а с линком удобнее кодить" или "Но никому это не надо."

S>А вот по твоим словам нужно выжимать все до остатка. Тогда на голый С

Слова "узкое место" в данном треде только в явном виде упоминаются не менее 10 раз. Но ты никак этого не замечаешь, а продолжаешь приписывать мне непойми что.

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

I>>Зависит от алгоритма, что очевидно. Сколько итераторов ты навернешь, столько и будет оверхеда. Сколько проходов по источнику, столько и оверхеда.
I>>Неужели непонятно?
S> Понятно. Но например Where объединять, а Select будут отжирать намного больше че MoveNext и Current
I>>Если это узкое место и от него можно избавиться, то зачем держаться за линк?
S> Нахрена мне экотнмить десятые миллисекунды, если читаемость линка намного выше?

1 давно у тебя часы стали "десятыми миллисекунды" ?
2 Если сервер держит 1000 запросов в секунду, то ухудшив на 1мс ты получаешь 500, а раз так — плати вдвое.

I>>Да ладно. Эдакая чудо-технология, которая только по назначению и применяется. Ага. Чудо — если девелопер пишет на линке, то он пишет правильно и применяет его правильно
S> Я на самом деле редко применяю линк, но там где это возможно использую с удовольствием. Производительность ну никак не проседает, ибо доля затрат мизерная.

Не проседет — не надо оптимизировать. Ты что, решил поспорить абы поспорить?

S>>> Минус то ты поставил!!

I>>Слова про 10, 100, 1000 раз это все про конкретные кейсы.
I>>Ты замеряешь другой кейс, делаешь вывод что все не так. Вот это и смешно.
S> Я замеряю отношение yield i++ c i++ ты же говорил о 1000. Разве нет?

Очевидно, что нет. Ты слишком много додумываешь вместо того, что бы взять да уточнить. .

I>>Так уже. Твоих вполне достаточно — тривиальный кейс дает замедление в 8 раз.
I>>Думаешь, более сложный будет быстрее работать?

S> Нет я показал как легко сделать и 3.5. Но никому это не надо. В реальных условиях это миллисекунды

"никому не надо" — это враньё.

Зависит от задачи.
В большинстве случаев это не критично.
В остальных случаях это становится узким место и нужно решать так или иначе.

"Но никому это не надо." — ты в который раз отрицаешь, что существует нечто вне твоего кругозора

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

I>1.5 ... 8.7 раза будут заметны всегда. Если у тебя процессинг с 1мс стал 2мс, то пропускная способность уменьшилась с 1000 запросов до 500.
I>Например, для облака это значит, что тебе надо платить вдвое больше при том же результате.
Когда идет разговор о долях миллисекунд. И главное доля в общем вычислениях на самом деле далеко не 100
Ты это и не заметишь даже на серверах. А что касается пользовательского кода с выводом на экран, или бд это вообще никто не заметит.
И главное, что такой кейс это 99.999% На всякие числодробилки ухот микроскопическая доля.
Для больших объемов существуют SQL. А там свои оптимизаторы. Больше затраты на передачу данных между процесами

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

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

I>>>А у тебя, похоже, нужно только за линк держаться, не дай бог отступить ради оптимизации

S>> Ну вот где я это писал? Я на самом деле линк не часто использую, но там где он более выразителен, я плевал на экономию пару миллисекунд.

I>Элементрарно — я пишу про узкое место, а ты тут же сунешь контр-аргумент "а с линком удобнее кодить" или "Но никому это не надо."

S>>А вот по твоим словам нужно выжимать все до остатка. Тогда на голый С

I>Слова "узкое место" в данном треде только в явном виде упоминаются не менее 10 раз. Но ты никак этого не замечаешь, а продолжаешь приписывать мне непойми что.
Так такой сценарий это 0.00001% но ты настаиваешь на этом мизерном сценарии!!!
И ставишь минуса. Пойми если бы были заметны тормоза никто бы линком и не пользовался. Там где они заметны конечно переходят на более оптимальные алгоритмы.
Но таких сценариев мизер!

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

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

I>>>Зависит от алгоритма, что очевидно. Сколько итераторов ты навернешь, столько и будет оверхеда. Сколько проходов по источнику, столько и оверхеда.
I>>>Неужели непонятно?
S>> Понятно. Но например Where объединять, а Select будут отжирать намного больше че MoveNext и Current
I>>>Если это узкое место и от него можно избавиться, то зачем держаться за линк?
S>> Нахрена мне экотнмить десятые миллисекунды, если читаемость линка намного выше?

I>1 давно у тебя часы стали "десятыми миллисекунды" ?
I>2 Если сервер держит 1000 запросов в секунду, то ухудшив на 1мс ты получаешь 500, а раз так — плати вдвое.
Еще раз. Я показал тебе разницу между res+=i и MoveNext и Current. В реалии это еще меньше и как правило больше уходит на сериализацию данных.

I>>>Да ладно. Эдакая чудо-технология, которая только по назначению и применяется. Ага. Чудо — если девелопер пишет на линке, то он пишет правильно и применяет его правильно
S>> Я на самом деле редко применяю линк, но там где это возможно использую с удовольствием. Производительность ну никак не проседает, ибо доля затрат мизерная.

I>Не проседет — не надо оптимизировать. Ты что, решил поспорить абы поспорить?
Зачем мне ловить миллисекунды? Зато код читаемый и проще находить ошиби. А оптимизацией заниматься тогда когда не хватает производительности.
Если её достаточно, то зачем вообще что то оптимизировать?
S>>>> Минус то ты поставил!!

I>>>Слова про 10, 100, 1000 раз это все про конкретные кейсы.
I>>>Ты замеряешь другой кейс, делаешь вывод что все не так. Вот это и смешно.
S>> Я замеряю отношение yield i++ c i++ ты же говорил о 1000. Разве нет?

I>Очевидно, что нет. Ты слишком много додумываешь вместо того, что бы взять да уточнить. .

То есть, если ты сотню раз будешь использовать источник такого вида

while(true) {
yield i++;
}

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

Это твои слова. На основании их я и сделал тест. А кэширование можно применять и с линком не проблема.

I>>>Так уже. Твоих вполне достаточно — тривиальный кейс дает замедление в 8 раз.
I>>>Думаешь, более сложный будет быстрее работать?
Сделай и покажи. Я тебе показал разнице между MoveNext Current относительно res+=i
S>> Нет я показал как легко сделать и 3.5. Но никому это не надо. В реальных условиях это миллисекунды

I>"никому не надо" — это враньё.

I>Зависит от задачи.
I>В большинстве случаев это не критично.
I>В остальных случаях это становится узким место и нужно решать так или иначе.

I>"Но никому это не надо." — ты в который раз отрицаешь, что существует нечто вне твоего кругозора
Так напиши свой Linq не проблема если так нужно. 99.9999% случаев обычного Linq достаточно.
Есть Roslyn linq-rewrite для оптимизации. Но ты его почему то игнорируешь

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

I>>Слова "узкое место" в данном треде только в явном виде упоминаются не менее 10 раз. Но ты никак этого не замечаешь, а продолжаешь приписывать мне непойми что.
S>Так такой сценарий это 0.00001% но ты настаиваешь на этом мизерном сценарии!!!

Вот снова отрицание. Ты, фактически, утверждаешь, что вне linq жизни нет.

S>И ставишь минуса. Пойми если бы были заметны тормоза никто бы линком и не пользовался. Там где они заметны конечно переходят на более оптимальные алгоритмы.

У тебя здесь противоречие. Якобы тормозов нет, но если они есть...

S>Но таких сценариев мизер!

Снова отрицание. Перформанс linq это по сей день один из популярных вопросов.

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

I>>1.5 ... 8.7 раза будут заметны всегда. Если у тебя процессинг с 1мс стал 2мс, то пропускная способность уменьшилась с 1000 запросов до 500.
I>>Например, для облака это значит, что тебе надо платить вдвое больше при том же результате.
S>Когда идет разговор о долях миллисекунд. И главное доля в общем вычислениях на самом деле далеко не 100

Это смотря какая задача.

S>Ты это и не заметишь даже на серверах. А что касается пользовательского кода с выводом на экран, или бд это вообще никто не заметит.
S>И главное, что такой кейс это 99.999% На всякие числодробилки ухот микроскопическая доля.

Снова отрицание. Ты сам то понимаешь, что раз за разом продолжаешь отрицать?

S>Для больших объемов существуют SQL. А там свои оптимизаторы. Больше затраты на передачу данных между процесами

Для больших объемов традиционные способы типа SQL не годятся.

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

I>>1 давно у тебя часы стали "десятыми миллисекунды" ?
I>>2 Если сервер держит 1000 запросов в секунду, то ухудшив на 1мс ты получаешь 500, а раз так — плати вдвое.
S> Еще раз. Я показал тебе разницу между res+=i и MoveNext и Current.

Стоит заметить, что сначала ты десятка два сообщений отрицал эту разницу. То есть — уже торг начался

>В реалии это еще меньше и как правило больше уходит на сериализацию данных.

Цитирую себя "Например, репортинг я весь перевел на IEnumerable<Е> и Linq." В репортинге конская доля времени это именно серилизация и подготовка html, excel и тд документа.

Что нового ты мне сказал?

I>>Не проседет — не надо оптимизировать. Ты что, решил поспорить абы поспорить?
S>Зачем мне ловить миллисекунды?

Ты забыл, что речь идет про bottle neck ?

> А оптимизацией заниматься тогда когда не хватает производительности.

Именно. Я про это и говорю. Слова "узкое место", "bottle neck" именно это и означают — не хватает производительности.

I>>Очевидно, что нет. Ты слишком много додумываешь вместо того, что бы взять да уточнить. .

S>То есть, если ты сотню раз будешь использовать источник такого вида
S>

S>while(true) {
S> yield i++;
S>}

S>То ты сэкономишь кучу памяти, но при этом работа с источником окажется примерно в 1000 раз медленнее.

S> Это твои слова. На основании их я и сделал тест.

Ты сделал другой тест Он показывает другой аспект — издержки на один итератор без цепочки.

> А кэширование можно применять и с линком не проблема.

Можно. Ты вообще читаешь, что я тебе пишу?

I>>>>Думаешь, более сложный будет быстрее работать?
S> Сделай и покажи. Я тебе показал разнице между MoveNext Current относительно res+=i

Какой в этом смысл? Доказать тебе существование нелинейных алгоритмов ? Или доказать, что цепочка итераторов работает медленее одного итератора?
Внятно скажи, что ты хочешь проверить тестом.

I>>"Но никому это не надо." — ты в который раз отрицаешь, что существует нечто вне твоего кругозора
S>Так напиши свой Linq не проблема если так нужно. 99.9999% случаев обычного Linq достаточно.

99.999% это статистика высосаная из пальца в момент написания сообщения. Между тем перформанс Linq до сих пор в топе вопросов.

S>Есть Roslyn linq-rewrite для оптимизации. Но ты его почему то игнорируешь

Насколько я понимаю, из твоих статей следует, что Roslyn решает далеко не все возможные проблемы.

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

I>Снова отрицание. Перформанс linq это по сей день один из популярных вопросов.
Есть Roslyn Linq Rewrite правда он для Core но не вижу проблем

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

S>>Есть Roslyn linq-rewrite для оптимизации. Но ты его почему то игнорируешь

I> Насколько я понимаю, из твоих статей следует, что Roslyn решает далеко не все возможные проблемы.
Не читал, но осуждаю. Все о чем ты тут говорил в большинстве Roslyn Linq Rewrite
И опять мы приходим к мизерной части

Supported LINQ methods
Select, Where, Reverse, Cast, OfType
First, FirstOrDefault, Single, SingleOrDefault, Last, LastOrDefault
ToList, ToArray, ToDictionary
Count, LongCount, Any, All
ElementAt, ElementAtOrDefault
Contains, ForEach

А насчет заинтересованности увеличения производительности Linq как ты говоришь, то я подымал тему 5 лет назад
http://www.rsdn.org/forum/dotnet/6565901.hot
Никого особо это не интересует как и количество issues
https://github.com/antiufo/roslyn-linq-rewrite/issues

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

I>>Снова отрицание. Перформанс linq это по сей день один из популярных вопросов.
S>Есть Roslyn Linq Rewrite правда он для Core но не вижу проблем

"не вижу проблем" это не аргумент. Как мне убрать издержки самих итераторов при помощи этого рослина?
Условно, хочу, как в С++ — итерация через итератор даёт ровно тот же ассемблерный код, что и обычный рукопашный вариант.
Как это сделать? А никак.
Понятно, что это нечастый случай. Но что делать, когда это именно он?

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

S>>>Есть Roslyn linq-rewrite для оптимизации. Но ты его почему то игнорируешь

I>> Насколько я понимаю, из твоих статей следует, что Roslyn решает далеко не все возможные проблемы.
S> Не читал, но осуждаю. Все о чем ты тут говорил в большинстве Roslyn Linq Rewrite
S>И опять мы приходим к мизерной части

Это снова отрицание вида "вне Linq жизни нет"

S>А насчет заинтересованности увеличения производительности Linq как ты говоришь, то я подымал тему 5 лет назад
S>http://www.rsdn.org/forum/dotnet/6565901.hot
S>Никого особо это не интересует как и количество issues

Вероятно, эта тема не интересует конкретно тебя, т.к. ты раз за разом доказываешь, что вне Linq жизни нет.
Судя по тому, что тебе 15 лет понадобилось что бы узнать про связь query comprehension и SelectMany, неудивительно.
Вобщем, на аргумент эти твои две ссылки не тянут.

S>https://github.com/antiufo/roslyn-linq-rewrite/issues

А зачем создавать issue на Roslyn, если многие вещи можно влёгкую оптимизировать руками?
Ты что, отложишь релиз приложения на месяцы или годы, и будешь ждать фичи?

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

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

I>>>Снова отрицание. Перформанс linq это по сей день один из популярных вопросов.
S>>Есть Roslyn Linq Rewrite правда он для Core но не вижу проблем

I>"не вижу проблем" это не аргумент. Как мне убрать издержки самих итераторов при помощи этого рослина?
I>Условно, хочу, как в С++ — итерация через итератор даёт ровно тот же ассемблерный код, что и обычный рукопашный вариант.
I>Как это сделать? А никак.
I>Понятно, что это нечастый случай. Но что делать, когда это именно он?

Ты вообще читатель? Там вообще при определенных условиях никаких итераторов и нет!!!

public int Method1()
{
    var arr = new[] { 1, 2, 3, 4 };
    var q = 2;
    return arr.Where(x => x > q).Select(x => x + 3).Sum();
}

Преобразуется в

public int Method1()
{
    int[] arr = new[] { 1, 2, 3, 4 };
    int q = 2;
    return this.Method1_ProceduralLinq1(arr, q);
}
private int Method1_ProceduralLinq1(int[] _linqitems, int q)
{
    if (_linqitems == null) throw new ArgumentNullException();

    int num = 0;
    for (int i = 0; i < _linqitems.Length; i++)
    {
        int num2 = _linqitems[i]; 
        if (num2 > q)
            num += num2 + 3;
    }
    return num;
}

Нука вручную сделай быстрее!

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


I>Вероятно, эта тема не интересует конкретно тебя, т.к. ты раз за разом доказываешь, что вне Linq жизни нет.
I>Судя по тому, что тебе 15 лет понадобилось что бы узнать про связь query comprehension и SelectMany, неудивительно.
I>Вобщем, на аргумент эти твои две ссылки не тянут.
Молодец!! Я знал, но забыл ибо не так часто пользуюсь. Но вот прибегать к такому аргументу.
Я показал какая хрень там выходит вместо коллекций
S>>https://github.com/antiufo/roslyn-linq-rewrite/issues

I>А зачем создавать issue на Roslyn, если многие вещи можно влёгкую оптимизировать руками?
I>Ты что, отложишь релиз приложения на месяцы или годы, и будешь ждать фичи?
Так вот какие народ фичи то хочет? Значит все есть или никому не упало эта оптимизация.
Вот ты даже и не знал о roslyn-linq-rewrite

Ну так пиши все на ассемблере. В легкую это обычно плохо читаемый код.
Просто на реальных данных экономить доли миллисекунд никому не интересно И таких как ты мизер!
Я сам редко использую линк но там где это возможно использую ради читаемости и сокращения кода.
Как правило затраты на линк намного меньше общих вычислений.
Но у тебя же повсеместно числодробилки с невероятно огромными данными. Не ну если пузырьковую сортировку использовать или прочие неоптимальные алгоритмы то конечно да.

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

I>>Условно, хочу, как в С++ — итерация через итератор даёт ровно тот же ассемблерный код, что и обычный рукопашный вариант.
I>>Как это сделать? А никак.
I>>Понятно, что это нечастый случай. Но что делать, когда это именно он?

S>Ты вообще читатель? Там вообще при определенных условиях никаких итераторов и нет!!!

Читай себя же: "при определенных условиях" Уже хорошо. Когда это помогает, конечно же это годный вариант.

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

S> Так вот какие народ фичи то хочет? Значит все есть или никому не упало эта оптимизация.

Я бы предположил, что изменения в структуре данных дают бОльший эффект. А может и линк в целом не такой уж и востребованый, как ты пишешь, даже с Рослином

S>Вот ты даже и не знал о roslyn-linq-rewrite

Что бы всё было в шоколаде, т.е. итерация по массиву вместо итератора, как ты показал, ктото же должен догадаться экспознуть соответсвующий интерфейс, а не бегать с воплями "и так сойдет патамушта рослин"
Более того, внутреннюю реализацию нужно так же подобрать под эту вот оптимизацию, иначе будет пшик.

S> Ну так пиши все на ассемблере. В легкую это обычно плохо читаемый код.
S>Просто на реальных данных экономить доли миллисекунд никому не интересно И таких как ты мизер!

Похоже, снова "вне линка жизни нет"

S>Я сам редко использую линк но там где это возможно использую ради читаемости и сокращения кода.
S>Как правило затраты на линк намного меньше общих вычислений.

Это никакое не правило, а всего лишь код общего назначения. Чуть что специализированое начинается — уже все идет не так, как тебе хочется.

S>Но у тебя же повсеместно числодробилки с невероятно огромными данными.

И что же делать, когда проект именно такой?