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

НС>>А почему да?
PJ>Я тебе написал почему да.

Ты написал то, что не имеет отношения к делу.

НС>>А назначение линка никак не меняет свойств добавленных конструкций.
PJ>Ну так и погоду линк не меняет, и что с того? Речь была о линке.

Речь была о том что он плохой, потому что это частный случай для коллекций.

НС>>Что эти фчи можно использовать не для коллекций.
PJ>Можно. А материал для шляпы может пойти на пальто. Но от этого шляпа пальтом не станет.

Доказательство по аналогии?

НС>>LINQ это тоже не фреймворк, а просто набор тех самых фич.
PJ>Ну это уже вообще чушь пошла.

Это факт.

PJ> МС не так релизила, МС не знает, что релизила.

МС все знает что релизила. Это вполне понятная маркетинговая политика.

PJ>И вообще верить надо тебе не документации с мсдн... В сад.

Где в документации с МСДН написано, что линк это частный случай для корллекций?

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

S>Есть ли что-либо подобное на других языках/платформах?
В Elixir (Ecto) есть. Например можно вот так написать (взято из доков, https://hexdocs.pm/ecto/Ecto.html):

query = from u in User,
          where: u.age > 18 or is_nil(u.email),
          select: u

# Returns %User{} structs matching the query
Repo.all(query)

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

PJ>Это делает этот самый зонтик linq — частным случаем для коллекций. Ни в каком другом виде их никто не объединяет.

Точно никто? А как же доступ к БД? А RX ? А XML?

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

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

Потери производительности будут в итераторах и вызове лямбд на каждый чих. Т.е. как только ты захочешь таким вот образом прощелкать всю коллекцию, ты получаешь замедление от 2 х и более раз, пропорционально длине цепочки комбинаторов. На больших коллекциях это просто конские издержки.
То есть, хорошо бы представить
1 количество элементов
2 что в конце — toArray или take(5)
3 и тд

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

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

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

I>Потери производительности будут в итераторах и вызове лямбд на каждый чих. Т.е. как только ты захочешь таким вот образом прощелкать всю коллекцию, ты получаешь замедление от 2 х и более раз, пропорционально длине цепочки комбинаторов. На больших коллекциях это просто конские издержки.
I>То есть, хорошо бы представить
I>1 количество элементов
I>2 что в конце — toArray или take(5)
I>3 и тд
Это все понятно. Оно будет и с итераторами с вычислением слева на право но с большим количеством итератация.
Вся прелесть yield, в том, что мы получаем объект с итератором и MoveNetx у оъекта с yield вызывает MoveNext у родительского итератора.

yield аналог коррутинов (fiber) для рекурсивного обхода структур. Во многих языках этого нет.
Я в начале для <+ деревьев сам писал такой итератор, но выходом .Net 2 MS как раз пришпондорили yield

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

I>Потери производительности будут в итераторах и вызове лямбд на каждый чих. Т.е. как только ты захочешь таким вот образом прощелкать всю коллекцию, ты получаешь замедление от 2 х и более раз, пропорционально длине цепочки комбинаторов. На больших коллекциях это просто конские издержки.
I>То есть, хорошо бы представить
I>1 количество элементов
I>2 что в конце — toArray или take(5)
I>3 и тд
Там на самом деле, по большому счёту, упирается всё в Multicast delegates.
Если б не они, то что бы мы имели?
Мы бы имели в list.Where.Where.Select.Count цепочку вызовов с константными аргументами. JIT мог бы это заметить: "о, мы передаём в select константный делегат, давайте его нафиг заинлайним".
Далее — по цепочке; и в конце мы получаем ровно тот же код, что и при компиляции

var c = 0;
foreach(var item in list)
{
  if ()
    if ()
      c++;
}

безо всяких выделений из кучи, виртуальных вызовов и т.п. Есть даже специальный рукопашный проект, который делает именно это: https://nessos.github.io/LinqOptimizer/

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

S>Это все понятно. Оно будет и с итераторами с вычислением слева на право но с большим количеством итератация.

Непонятно, что тебе понятно В одном месте ты пишешь, что потерь производительности нет, а в другом — что они есть.

На самом деле пенальти на итерацию есть всегда. Для ленивых вычислений это относительно малое значение. Но, скажем, как только весь сервер целиком начинает обрабатывать коллекции в подобном виде, загрузка процессора увеличивается пропорционально и throughput падает обратно пропорционально, т.е. от 2х и более раз.

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

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

А при чем здесь MD? Разве выражение выше не развернется в 3 (или 4?) цикла, т.е.where->where->select->(?)count?
Разве будет один цикл с MD?

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

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

S>>Это все понятно. Оно будет и с итераторами с вычислением слева на право но с большим количеством итератация.

I>Непонятно, что тебе понятно В одном месте ты пишешь, что потерь производительности нет, а в другом — что они есть.

I>На самом деле пенальти на итерацию есть всегда. Для ленивых вычислений это относительно малое значение. Но, скажем, как только весь сервер целиком начинает обрабатывать коллекции в подобном виде, загрузка процессора увеличивается пропорционально и throughput падает обратно пропорционально, т.е. от 2х и более раз.

Я говорил, про то, что к списку того, что Linq , при кажущейся простоте, потребовал: нужно добавить yield. Ты с этим не согласен?

Что касается оптимизаций, то они есть roslyn-linq-rewrite

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

Сначала C# ники встретили Linq настороженно, но потом удобство перевысили потери в производительности

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

S>А при чем здесь MD?
При том, что инлайнинг делегатов в дотнете невозможен, даже спекулятивно. И невозможен он в первую очередь из-за того, что формально в любом месте в цепочке where.where.select может оказаться делегат с несколькими target, поэтому JIT даже не пытается делегаты инлайнить.
S>Разве выражение выше не развернется в 3 (или 4?) цикла, т.е.where->where->select->(?)count?
S>Разве будет один цикл с MD?
с MD тоже будет один цикл. Но на каждой итерации цикла будет 4 крайне дорогостоящих вызова делегата, на каждой итерации цикла будет порождаться временный объект в куче, плюс ещё восемь объектов будут созданы для итераторов и энумераторов.

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

S> Я говорил, про то, что к списку того, что Linq , при кажущейся простоте, потребовал: нужно добавить yield. Ты с этим не согласен?

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

Ты забыл эту часть своего утверждения?

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

А ты сравнивал показания профайлера? Я вот взял да сравнил и выяснил, что для энергичных вычислений Linq даёт существенное замедление.
Для ленивых вычислений собственно ровно то же, но тут дело в отсутствии альтернативы. Или много сложного ручного кода, или короткий вариант на Linq
Тем не менее, пенальти никуда не девается.

S>Сначала C# ники встретили Linq настороженно, но потом удобство перевысили потери в производительности

Да, я помню форматтер кода от джетбрейнс в решарпере на linq Который тормозил и мог сожрать всю память.

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

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

S>> Я говорил, про то, что к списку того, что Linq , при кажущейся простоте, потребовал: нужно добавить yield. Ты с этим не согласен?

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

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

I>А ты сравнивал показания профайлера? Я вот взял да сравнил и выяснил, что для энергичных вычислений Linq даёт существенное замедление.
I>Для ленивых вычислений собственно ровно то же, но тут дело в отсутствии альтернативы. Или много сложного ручного кода, или короткий вариант на Linq
I>Тем не менее, пенальти никуда не девается.

Я уже лет двадцать сравниваю. Те же сортировки и прочие лабуду где используются дженерики без инлайнинга.
По твоему нужно отказаться и от дженериков?
Да и хрен с ним с этими пенальти. Важно скорость кодирования и легкость понимания кода.
S>>Сначала C# ники встретили Linq настороженно, но потом удобство перевысили потери в производительности

I>Да, я помню форматтер кода от джетбрейнс в решарпере на linq Который тормозил и мог сожрать всю память.

Во многих случаях просто невозможно без Linq. Но и в том же Linq ты можешь использовать расширения, где можно инлайнить нужный компаратор.
Там всего то будет 2 сточки кода с yield
И при этом все равно будет удобнее чем ручная реализация цепочки отборов, сортировок. Да на 1-2 проблем нет, но на 5 уже код нечитаемый
И в реалиях нужно применять динамически фильтры, соединения
Ну а сжирал память уж точно не из-за Linq.

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

S>>А при чем здесь MD?
S>При том, что инлайнинг делегатов в дотнете невозможен, даже спекулятивно. И невозможен он в первую очередь из-за того, что формально в любом месте в цепочке where.where.select может оказаться делегат с несколькими target, поэтому JIT даже не пытается делегаты инлайнить.

target -- в смысле число делегатов (+=)?

S>>Разве выражение выше не развернется в 3 (или 4?) цикла, т.е.where->where->select->(?)count?
S>>Разве будет один цикл с MD?
S>с MD тоже будет один цикл. Но на каждой итерации цикла будет 4 крайне дорогостоящих вызова делегата, на каждой итерации цикла будет порождаться временный объект в куче, плюс ещё восемь объектов будут созданы для итераторов и энумераторов.

Откуда временный объект в куче? И почему именно 8 объектов для итераторов и энумераторов, а не один итератор и энумератор для всего MD?

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

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

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

S>Там на самом деле, по большому счёту, упирается всё в Multicast delegates.

Замеры реального кода показывают, что чаще упирается во время создания цепочки итераторов. Когда у тебя в коллекции много элементов, оно некритично, но вот когда их несколько штук или несколько десятков — создание итераторов занимает больше времени, чем собственно обход.

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

I>Да, я помню форматтер кода от джетбрейнс в решарпере на linq Который тормозил и мог сожрать всю память.

В форматтере R# совсем нет линка. Там голые циклы и даже goto. И тормозит он не из за этого, а из-за того что правит живое AST, на каждое изменение которого навешена целая куча события с пачкой обработчиков. Архитектура базовая у него дырявая, и на этом фоне тормоза линка не увидеть и в микроскоп.

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

НС>В форматтере R# совсем нет линка. Там голые циклы и даже goto. И тормозит он не из за этого, а из-за того что правит живое AST, на каждое изменение которого навешена целая куча события с пачкой обработчиков. Архитектура базовая у него дырявая, и на этом фоне тормоза линка не увидеть и в микроскоп.

А как нужно было?

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

S>А как нужно было?

Без событий на изменение каждого узла дерева. Да и саму структуру дерева можно было пооптимальнее спроектировать, с меньшим количеством неоднозначностей и более удобной структурой для обработки.

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

I>>Да, я помню форматтер кода от джетбрейнс в решарпере на linq Который тормозил и мог сожрать всю память.

НС>В форматтере R# совсем нет линка.

А ты в своём репертуаре У меня фраза в прошедшем времени, а у тебя в настоящем. Если хотел чего то опровергнуть, то надо было начинать так: "...никогда не было"

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

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

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

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

Linq крут не потому, что не тормозит, а потому, что может дать бенефит который перекроет эту пенальти. Но цену то всё равно надо учитывать, а не просто херачить "и так сойдёт, это ж Linq".

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

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

По моему нужно перестать додумывать за меня.

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

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

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

Память это хрен с ним, больше тормоза беспокоили из за кода написаного на linq.