Re[13]: Есть ли подобие LINQ на других языках/платформах?
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.04.21 14:23
Оценка:
Здравствуйте, 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 отстой!!!
Ты наверное на С++ пишешь?
и солнце б утром не вставало, когда бы не было меня
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.