Здравствуйте, 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 равна нулю.
Нет, но она значительно меньше если писать расширения без yield, потому что придется вычислять слева направо с кучей лишних циклов.

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, Вы писали:

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 ?

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