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


I>Это смотря какая цель. Есть много мест куда тащить Linq ну никак не стоит. Есть вполне осязаемая граница, после которой от Linq одни убытки.

Например? Пример границы можно?

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

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

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

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

I>Ну будет одна. И что с того? Пенальти то всё равно есть. Тыща запросов из одной итерации всё равно дадут xN ко времени процессинга. Только узнаешь об этом по времени загрузки процессора или счетчиках в клауде, а не по времени одного запроса.
Нет не будет если ты напишешь свое расширение из 2 строк! Опять же речь шла про yield!!!

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

S>> Я уже лет двадцать сравниваю. Те же сортировки и прочие лабуду где используются дженерики без инлайнинга.
S>>По твоему нужно отказаться и от дженериков?

I>По моему нужно перестать додумывать за меня.
Ну так там используются интерфйсы и делегаты. Это же тебе противно!

S>> Да и хрен с ним с этими пенальти. Важно скорость кодирования и легкость понимания кода.

I>Это смотря какая цель. Есть много мест куда тащить Linq ну никак не стоит. Есть вполне осязаемая граница, после которой от Linq одни убытки.

S>>Ну а сжирал память уж точно не из-за Linq.

I>Память это хрен с ним, больше тормоза беспокоили из за кода написаного на linq.
Ну ты все таки пропустил пункт с написанием своих расширений. С yield это всего 2 строчки кода. Но ты решил опустить этот пункт.
И я писал про производительность именно про то, что обход в Linq идет с права налево, и про лямбды я не писал, но воткнул свои 5 копеек, но когда тебе пишут как решить проблемы, ты эти пункты просто опускаешь.
В том числе https://github.com/antiufo/roslyn-linq-rewrite
Там где есть лимитирующая стадия там и нужно оптимизировать. Решений много, но это не факт отказываться от Linq

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

I>>Ну будет одна. И что с того? Пенальти то всё равно есть. Тыща запросов из одной итерации всё равно дадут xN ко времени процессинга. Только узнаешь об этом по времени загрузки процессора или счетчиках в клауде, а не по времени одного запроса.
S>Нет не будет если ты напишешь свое расширение из 2 строк! Опять же речь шла про yield!!!

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

S> А кто говорил, что не нужно учитывать? Есть профайлеры и находится лимитирующая стадия процесса, если скорости недостаточно.

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

S>А в итоге найдется не в линк, а в других кривых ручках.

Ты только что говорил про некое мифическое удобство. а щас вот "кривые руки"

I>>>>Для ленивых вычислений собственно ровно то же, но тут дело в отсутствии альтернативы. Или много сложного ручного кода, или короткий вариант на Linq
I>>>>Тем не менее, пенальти никуда не девается.
S>Еще раз напиши свое расширение с инлайнингом лямбды. В чем проблема если ты так печешься о скорости используй roslyn-linq-rewrite

I>>По моему нужно перестать додумывать за меня.
S> Ну так там используются интерфйсы и делегаты. Это же тебе противно!

В дженериках интерфейсы и делегаты? Ты бы яснее мысли выражал.

I>>Память это хрен с ним, больше тормоза беспокоили из за кода написаного на linq.
S> Ну ты все таки пропустил пункт с написанием своих расширений. С yield это всего 2 строчки кода. Но ты решил опустить этот пункт.

Ты снова утверждаешь, что стоимость yield равна нулю.

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

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

S> В том числе https://github.com/antiufo/roslyn-linq-rewrite

Еще одно решение для проблемы которой нет. Ты сам то понял, что показываешь? На кой ляд этот Рослин, если издержки yield равны нулю?

S>Там где есть лимитирующая стадия там и нужно оптимизировать. Решений много, но это не факт отказываться от Linq

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

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

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

I>>>Ну будет одна. И что с того? Пенальти то всё равно есть. Тыща запросов из одной итерации всё равно дадут xN ко времени процессинга. Только узнаешь об этом по времени загрузки процессора или счетчиках в клауде, а не по времени одного запроса.
S>>Нет не будет если ты напишешь свое расширение из 2 строк! Опять же речь шла про yield!!!

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

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

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

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

S>> А кто говорил, что не нужно учитывать? Есть профайлеры и находится лимитирующая стадия процесса, если скорости недостаточно.

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

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

S>>А в итоге найдется не в линк, а в других кривых ручках.

I>Ты только что говорил про некое мифическое удобство. а щас вот "кривые руки"

I>>>>>Для ленивых вычислений собственно ровно то же, но тут дело в отсутствии альтернативы. Или много сложного ручного кода, или короткий вариант на Linq
I>>>>>Тем не менее, пенальти никуда не девается.
S>>Еще раз напиши свое расширение с инлайнингом лямбды. В чем проблема если ты так печешься о скорости используй roslyn-linq-rewrite

I>>>По моему нужно перестать додумывать за меня.
S>> Ну так там используются интерфйсы и делегаты. Это же тебе противно!

I>В дженериках интерфейсы и делегаты? Ты бы яснее мысли выражал.
Для сортровок и прочих обобщенных действий передаются для каждого типа интерфейсы или делегаты
I>>>Память это хрен с ним, больше тормоза беспокоили из за кода написаного на linq.
S>> Ну ты все таки пропустил пункт с написанием своих расширений. С yield это всего 2 строчки кода. Но ты решил опустить этот пункт.

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

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

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

I>По твоему, проблемы нет, потому есть её решение ? Если надо изыскивать особые комбинаторы, это значит, что просто так само работать не будет.
Если есть проблема которую можно решить через раширение то почему бы и нет?
S>> В том числе https://github.com/antiufo/roslyn-linq-rewrite

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

Посмотри разницу с LinqOptimizer


S>>Там где есть лимитирующая стадия там и нужно оптимизировать. Решений много, но это не факт отказываться от Linq

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

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

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

Вот ты мне минус поставил, значит не согласен с тем, что yield является необходимой составляющей для появления Linq?

Здравствуйте, 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 есть всегда. Странно с этим спорить. Стоимость итерации вполне осязаема.
Пенальти и тормоза это разные вещи.

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

S> Вот ты мне минус поставил, значит не согласен с тем, что yield является необходимой составляющей для появления Linq?

Десяток сообщений не помог понять, с чем я не согласен?

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

S>Мы бы имели в list.Where.Where.Select.Count цепочку вызовов с константными аргументами. JIT мог бы это заметить: "о, мы передаём в select константный делегат, давайте его нафиг заинлайним".

Это должен делать не джит, а расширялки компилятора.

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

I>Здравствуйте, 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>> То как видишь никаких тормозов на лямбдах нет

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

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

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

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

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

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

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

I>Ога.

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

I>Ленивость можно сделать и без linq. И точно так же расходов будет меньше, как раз на этот самый yield.
Linq как рах использует ленивость чере yield!!!
I>И точно так же это проявится на большом количестве запросов. Загрузка процессора увеличится во столько раз, во сколько yield превышает твои if и %
Вызов MoveNext соизмерима с вызовом метода то есть где то в 2 раза выше %. То есть максимально скороть ниже в 2 раза на простых методас с int, но меньше чем при работе со строками ил double

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

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

I>Не недо никаких лишних циклов. Ты руками то пробовал ленивость реализовывать?
Конечно. Я же писал Б+ деревья

Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

с рекурсивным обходом. Через yield это пишется в 4 строки.
Например

public IEnumerable<int> EnumerateIntInRec(Node node)
{
   if (node == null) yield break;
   foreach (int ch in EnumerateIntInRec(node.left)) yield return ch;
   yield return node.Value;
   foreach (var ch in EnumerateIntInRec(node.right)) yield return ch;
}

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

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


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

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

I>Вот-вот. Покажи как от yield избавиться.
Зачем!!!
I>>> Процитируй, где именно я призываю отказаться от linq ?

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

I>Я пишу о том, что пенальти на yield есть всегда. Странно с этим спорить. Стоимость итерации вполне осязаема.
I>Пенальти и тормоза это разные вещи.
Ты на все пункты отвечай, а не только на те, что удобны я привел тебе пример где yield обгонять list.Add но ты все утверждаешь, что yield отстой!!!
Ты наверное на С++ пишешь?

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

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

S>> Вот ты мне минус поставил, значит не согласен с тем, что yield является необходимой составляющей для появления Linq?

I>Десяток сообщений не помог понять, с чем я не согласен?
Не так и не понял и ты так в итоге и сам не ответил.
А в сообщении было написано что "yield является необходимой составляющей для появления Linq"
В чем ты не согласен. Ответь прямо. Является или нет!
Ты же понес пургу про пенальти и прочую лабуду про потерю производительности
.
Так ответь же на поставленный вопрос!!

Я поправил соббщение

Еще нужно добавить про yield и ленивое выполнение.
То есть при выполнении цепочки

list.Where.Where.Select.Count
List пройдет всего один цикл ибо выполнение начнется с права на лево
Count вызовет MoveNext у Select, Select у Where и так далее.
По этому мы можем объединять Where без потери производительности на лишние циклы

С чем ты не согласен

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

S>>> Вот ты мне минус поставил, значит не согласен с тем, что yield является необходимой составляющей для появления Linq?

I>>Десяток сообщений не помог понять, с чем я не согласен?
S>Не так и не понял и ты так в итоге и сам не ответил.

Я уже отвечал на этот вопрос и даже процитировал, с чем именно не согласен.

C Linq мы можем небольшими трудозатратами обеспечить ленивые вычисления с некоторыми пенальти. При этом пенальти всё равно будут, всегда, как бы ты ни приседал. Более того — профит будет только в определенной области. Вне её эти пенальти начинают перевешивать все бенефиты.
Например, если в числодробилке время в итерациях процентов 80%, то это значит, что можно соптимизировать по CPU раза в два-три просто отказавшись от Linq.

В обычных задачах на сами итерации расходуется ничтожное количество времени. Потому замедлив участок даже в 10 раз, ты в целом ничего не теряешь, т.к. компенсация благодаря ленивым вычислениям может дать гораздо больше.
Или например в интерактивных сценариях нас вобщем не сильно заботит загрузка процессора, в отличие от серверных. Ну вырастет время обработки данных с милисекунд до десятков или сотен милисекунд — ничего страшного.
Потому мерить надо не абы что, а смотреть контекст и долю linq в вычислениях.

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

I>C Linq мы можем небольшими трудозатратами обеспечить ленивые вычисления с некоторыми пенальти. При этом пенальти всё равно будут, всегда, как бы ты ни приседал. Более того — профит будет только в определенной области. Вне её эти пенальти начинают перевешивать все бенефиты.
I>Например, если в числодробилке время в итерациях процентов 80%, то это значит, что можно соптимизировать по CPU раза в два-три просто отказавшись от Linq.

I>В обычных задачах на сами итерации расходуется ничтожное количество времени. Потому замедлив участок даже в 10 раз, ты в целом ничего не теряешь, т.к. компенсация благодаря ленивым вычислениям может дать гораздо больше.
I>Или например в интерактивных сценариях нас вобщем не сильно заботит загрузка процессора, в отличие от серверных. Ну вырастет время обработки данных с милисекунд до десятков или сотен милисекунд — ничего страшного.
I>Потому мерить надо не абы что, а смотреть контекст и долю linq в вычислениях.

Это все прекрасно но как это связано с

Еще нужно добавить про yield и ленивое выполнение.
То есть при выполнении цепочки

list.Where.Where.Select.Count
List пройдет всего один цикл ибо выполнение начнется с права на лево
Count вызовет MoveNext у Select, Select у Where и так далее.
По этому мы можем объединять Where без потери производительности на лишние циклы

Я говорил про yield и ленивые вычисления при которых происходит вычисление справа на лево и избавляемся от лишних циклов?

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

IT>Это должен делать не джит, а расширялки компилятора.
Это как это? Компилятор видит вызов метода с сигнатурой Where(IEnumerable<T> this, Predicate<T> condition).
Ты предлагаешь ему заменить этот вызов на инлайн метода Where, а потом результат инлайна просмотреть на предмет возможности заинлайнить вызов condition?
Для этого ему нужно иметь доступ к телу метода Where, и вообще способность инлайнить IL-код, которой у него, афаик, в настоящее время нету вовсе.

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

IT>>Это должен делать не джит, а расширялки компилятора.
S>Это как это? Компилятор видит вызов метода с сигнатурой Where(IEnumerable<T> this, Predicate<T> condition).
S>Ты предлагаешь ему заменить этот вызов на инлайн метода Where, а потом результат инлайна просмотреть на предмет возможности заинлайнить вызов condition?
S>Для этого ему нужно иметь доступ к телу метода Where, и вообще способность инлайнить IL-код, которой у него, афаик, в настоящее время нету вовсе.

Нет, ничего этого не надо. Дайте мне возможность написать полноценный плагин для компилятор и завтра (ну там как-нибудь скоро) весь Enumerable будет инлайниться только так.

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

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

НС>>В форматтере R# совсем нет линка.
I>А ты в своём репертуаре У меня фраза в прошедшем времени, а у тебя в настоящем.

Прошедшее это какое? В 2008 там его не было, а код был стар на тот момент, как говно мамонта.

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

I>>В обычных задачах на сами итерации расходуется ничтожное количество времени. Потому замедлив участок даже в 10 раз, ты в целом ничего не теряешь, т.к. компенсация благодаря ленивым вычислениям может дать гораздо больше.
I>>Или например в интерактивных сценариях нас вобщем не сильно заботит загрузка процессора, в отличие от серверных. Ну вырастет время обработки данных с милисекунд до десятков или сотен милисекунд — ничего страшного.
I>>Потому мерить надо не абы что, а смотреть контекст и долю linq в вычислениях.

S> Это все прекрасно но как это связано с

S>

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

S> Я говорил про yield и ленивые вычисления при которых происходит вычисление справа на лево и избавляемся от лишних циклов?

yield сам по себе вносит потери. Неважно, есть лишние циклы, или нет. x[i] заменяется на доступ через итератор. Вот уже проблема.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>В форматтере R# совсем нет линка.
I>>А ты в своём репертуаре У меня фраза в прошедшем времени, а у тебя в настоящем.

НС>Прошедшее это какое? В 2008 там его не было, а код был стар на тот момент, как говно мамонта.

.net 3.5, т.е. c linq, вышел в конце 2007го года. Вероятно, в 2008 еще не успели натаскать, а вот примерно к 2009..2011му постарались И потом снова выбросили. Ориентировочно, по времени до выпуска dotMemory 64.
Собственно, эта штука обсуждалась на сколько помню на рсдн. Лень искать.

Здравствуйте, 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 будут равны нулю на таком фоне. Вероятно ты замерял перформанс именно в таком вот контексте.

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

S>> Я говорил про yield и ленивые вычисления при которых происходит вычисление справа на лево и избавляемся от лишних циклов?

I>yield сам по себе вносит потери. Неважно, есть лишние циклы, или нет. x[i] заменяется на доступ через итератор. Вот уже проблема.


То есть ты не согласен с тем, что без yield был бы возможен Linq?
С yield IEnumerable создается автоматически. Заметь IEnumerable! Если тебе где то в конце цепочки вызовов итераторов понадобится Top(5) или FirstOrDefault
то тебе не нужно перебирать всю коллекцию (возможно и не один раз) и вызвать все лямбды, new в цепочке расширений если вычисления идут слева направо.
Но для тебя же это не затраты!!

То что ты пишешь ну никак не относится к

Еще нужно добавить про yield и ленивое выполнение.
То есть при выполнении цепочки

list.Where.Where.Select.Count
List пройдет всего один цикл ибо выполнение начнется с права на лево
Count вызовет MoveNext у Select, Select у Where и так далее.
По этому мы можем объединять Where без потери производительности на лишние циклы

К которому ты упорно ставишь минусы и при этом сваливаешься на производительность yield.
yield создает объект класса реализующий IEnumerable.
Как замедляется доступ к энумератору если он вызывает MoveNext. Передается то IEnumerable а не List или array.
На этом основан Linq!
Да можно оптимизировать и инлайнить, но мало кому это нужно. Я тебе приводил примеры на оптимизацию Linq https://mattwarren.org/2016/09/29/Optimising-LINQ/
И поверь мало кто ими пользуются.

Но это все лирика.

Еще раз ответь с чем ты не согласен?
Основной посыл сообщения в том, что не было бы Linq без yield

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

НС>>Прошедшее это какое? В 2008 там его не было, а код был стар на тот момент, как говно мамонта.
I>.net 3.5, т.е. c linq, вышел в конце 2007го года. Вероятно, в 2008 еще не успели натаскать, а вот примерно к 2009..2011му постарались

До 2010 там точно никакого линка не было.

I>Собственно, эта штука обсуждалась на сколько помню на рсдн. Лень искать.

Обсуждалась на рсдн другая история, не про форматтер. В форматтере линка никогда не было.