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

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

I>>> Вот еще одно заблуждение. С С++ и джавой ты не знаком?
S>> Ииииииииииииии. Охренительный ответ.
S>> Приводи код!! Знаком и там нет yield там и Linq нет!!

I>Ты адекватен, в джаве Linq искать? Там есть streams, которые покрывают твой любимый linq2objects
I>

I>Employee employee = Stream.of(empIds)
I>      .map(employeeRepository::findById)
I>      .filter(e -> e != null)
I>      .filter(e -> e.getSalary() > 100000)
I>      .findFirst()
I>      .orElse(null);
I>

И. Еще раз там используются ленивые иераторы?
Сколько в итоге будет итераций?
https://stackoverflow.com/questions/21782380/are-java-8-streams-the-same-as-net-ienumerable

You would expect the stream() method to be on Iterable, in the same way as LINQ operates on IEnumerable, but it's on Collection instead. Perhaps it's because Java lacks yield-return semantics, so Iterable is just less interesting or useful in Java.

I>>>А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
I>>>Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.
S>> Какую!!! Ты хоть напиши какую!!!

I>Четвертый раз — вместо x[i] у тебя MoveNext, проход через switch, присваивание Current и чтение Current
I>И вот эта каша крайне плохо инлайнится, а следовательно ест больше чем весит.
I>Заметь — это уже в четвертый раз я пишу, а до тебя не доходит.

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

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

I>>>Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.
S>>Причем тут числодробилки! Ты ратуешь за IQueriable. Вон Sinclair пришпондорил Linq.

I>IQueryable нужен там, где будет обработка Expression и нужен единый подход вне зависимости, BD или коллекции.
I>То есть, избавляет от дублирования.
I>Если это не является узким местом для перформанса — используй сколько хошь.

I>>>Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.
S>>Ну то есть ты за выполнение слева направо.
Где и какой профайлер?? Покажи данные!
I>Откуда такой вывод? Я и слева направо обгоню это IEnumerable с не меньшим бенефитом.
Даааа!! вот твой же пример с миллионами строк пр этом первая же строка удовлетворяе условию.
Вот такие у тебя профайлеры. Но минус то ты мне ставишь!!

S>>же не заставляет использовать тебя IEnumerablt используй IList и обходись без ленивости.

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

S>>Только то вот Linq ленив и ленивость эту в основном создает yield с созданием определенных классов автоматов с сохранением состояния

I>Вот снова ересь — ленивость создаёт сам IEnumerable и никак иначе. Вобщем, каша. То одно пишешь, то другое, прямо противоположное
Нет. Заполнение List не лениво!!!!!
Вот именно, сам разберись. Пока все не в тему. И ну и явно ты не разобрался с темой.
Почитай https://pvs-studio.com/ru/b/0808/#ID4EFF844D56

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

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

I>>> Вот еще одно заблуждение. С С++ и джавой ты не знаком?
S>> Ииииииииииииии. Охренительный ответ.
S>> Приводи код!! Знаком и там нет yield там и Linq нет!!

I>Ты адекватен, в джаве Linq искать? Там есть streams, которые покрывают твой любимый linq2objects
I>

I>Employee employee = Stream.of(empIds)
I>      .map(employeeRepository::findById)
I>      .filter(e -> e != null)
I>      .filter(e -> e.getSalary() > 100000)
I>      .findFirst()
I>      .orElse(null);
I>

И. Еще раз там используются ленивые иераторы?
Сколько в итоге будет итераций?
https://stackoverflow.com/questions/21782380/are-java-8-streams-the-same-as-net-ienumerable

You would expect the stream() method to be on Iterable, in the same way as LINQ operates on IEnumerable, but it's on Collection instead. Perhaps it's because Java lacks yield-return semantics, so Iterable is just less interesting or useful in Java.

I>>>А чуть выше ты соскакиваешь с цены в рантайме на цену в разработке.
I>>>Например, когда я пишу, что IEnumerable имеет свою цену, ты начинаешь вещать про разработку.
S>> Какую!!! Ты хоть напиши какую!!!

I>Четвертый раз — вместо x[i] у тебя MoveNext, проход через switch, присваивание Current и чтение Current
I>И вот эта каша крайне плохо инлайнится, а следовательно ест больше чем весит.
I>Заметь — это уже в четвертый раз я пишу, а до тебя не доходит.

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

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

I>>>Это нужный сахар. И тем не менее его нельзя использовать бездумно. В числодробилках он может давать конские потери.
S>>Причем тут числодробилки! Ты ратуешь за IQueriable. Вон Sinclair пришпондорил Linq.

I>IQueryable нужен там, где будет обработка Expression и нужен единый подход вне зависимости, BD или коллекции.
I>То есть, избавляет от дублирования.
I>Если это не является узким местом для перформанса — используй сколько хошь.

I>>>Именно. Профайлер утверждает, что экономия может быть и полтора, и два, и даже десять раз.
S>>Ну то есть ты за выполнение слева направо.
Где и какой профайлер?? Покажи данные!
I>Откуда такой вывод? Я и слева направо обгоню это IEnumerable с не меньшим бенефитом.
Даааа!! вот твой же пример с миллионами строк пр этом первая же строка удовлетворяе условию.
Вот такие у тебя профайлеры. Но минус то ты мне ставишь!!

S>>же не заставляет использовать тебя IEnumerablt используй IList и обходись без ленивости.

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

S>>Только то вот Linq ленив и ленивость эту в основном создает yield с созданием определенных классов автоматов с сохранением состояния

I>Вот снова ересь — ленивость создаёт сам IEnumerable и никак иначе. Вобщем, каша. То одно пишешь, то другое, прямо противоположное
Нет. Заполнение List не лениво!!!!!
Вот именно, сам разберись. Пока все не в тему. И ну и явно ты не разобрался с темой.
Почитай https://pvs-studio.com/ru/b/0808/#ID4EFF844D56