Здравствуйте, Serginio1, Вы писали:
S> Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя. S>Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.
Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>> Если не нравится голый ADO в руки или предварительная компиляция. Каждый выбирает для себя. S>>Особенно когда запрос на несколько страниц, дополнительные две строчки никакой роли не играет.
_>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.
Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.
В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.
Здравствуйте, Ikemefula, Вы писали:
EP>>Сравниваем. Вариант Boost.Range: EP>>1. Лаконичнее, красивее. I>А всякие _1 это полагаю эталон красоты ?
Да, это самый короткий и лаконичный вариант.
I>А если надо сравнивать не с константой ?
Без проблем.
EP>>2. Быстрее. Там под копотом кстати те самые итераторы. I>Для ленивого кода — даже не смешно.
Расшифруй.
EP>>3. Выдаёт bidirectional последовательность вместо forward/single pass. I>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007.
В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость.
I>Бидирекшинал это очень жосткое органичение само по себе.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>А всякие _1 это полагаю эталон красоты ?
EP>Да, это самый короткий и лаконичный вариант.
Это просто зипование-обфускация кода.
I>>А если надо сравнивать не с константой ?
EP>Без проблем.
Не верю
EP>>>2. Быстрее. Там под копотом кстати те самые итераторы. I>>Для ленивого кода — даже не смешно.
EP>Расшифруй.
Очень просто — для ленивого кода производительность это сильно второстепенный показатель.
EP>>>3. Выдаёт bidirectional последовательность вместо forward/single pass. I>>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007. EP>В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость.
Ты бы поменьше врал, что ли ? Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.
Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для
while (true){ yield return Guid.New(); }
Код в студию. Оправдания и всякие "но... а вот я... а давай по другому..." не принимаются.
Не нравится этот вариант — покажи, скажем, получение данных от DB и тд
I>>Бидирекшинал это очень жосткое органичение само по себе.
EP>Так Forward/Single Pass ещё жёстче.
Здравствуйте, alex_public, Вы писали:
_>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
Ну да, сначала 3-5 лет нарабатывать квалификацию и вырабатывать условные рефлексы, одевая штаны через голову, а потом всё просто — норма.
Самое интересное, что среди плюсовиков крайне мало людей, которые умеют писать и быстрый и удобный и стабильный код. Я бы сказал случаи единичные.
Сейчас найм внятных плюсовиков это сумасшедший головняк для HR, хуже наверное только найм всякой экзотики или какого лиспа.
_>Это всё рекламные выступления. ) А вот в обсуждение по ссылке выше были уже реальные результаты. Причём не от всяких там C++'ков, а от спецов по C#, которые тоже весьма недовольны быстродействием EF.
Ты бы про ту ссылку забыл и не вспоминал, тебя там тыкали головой в твое невежество и незнание БД весь топик.
Здравствуйте, Ikemefula, Вы писали:
I>>>А если надо сравнивать не с константой ? EP>>Без проблем. I>Не верю
Мне всё равно, в корутины ты тоже не верил
EP>>>>2. Быстрее. Там под копотом кстати те самые итераторы. I>>>Для ленивого кода — даже не смешно. EP>>Расшифруй. I>Очень просто — для ленивого кода производительность это сильно второстепенный показатель.
Аргументы?
EP>>>>3. Выдаёт bidirectional последовательность вместо forward/single pass. I>>>Я даже не помню, когда последний раз нужен был этот самый бидирекшинал. Может лет 5 назад а может и вообще году в 2007. EP>>В этом случае Bidirectional, в других Random. В то время как на LINQ приходится делать копии убивающие ленивость. I>Ты бы поменьше врал, что ли ?
Проходили уже, сначала ты десятки страниц кричишь вывсёврёте, этовсёнеправда, а потом "ой".
I>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.
Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional
I>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для
Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Без проблем. I>>Не верю
EP>Мне всё равно, в корутины ты тоже не верил
Если точнее, ты отрицал и продолжаешь отрицать наличие проблем из за внедрения короутин.
Ну, то есть, код который был исключительно однозадачным, нереэнтерабельным, вдруг стал многозадачным, реэнтерабельным, каким то чудом должен корректно работать
EP>>>Расшифруй. I>>Очень просто — для ленивого кода производительность это сильно второстепенный показатель.
EP>Аргументы?
Ленивость, если отбросить твои любимые массивы, есть это отказ от "тянем всё целиком и долго-долго считаем" в пользу "грузими кусочками", "считаем кусочками".
Т.е. сознательно вводим задержки по времени.
Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки !
По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки !
То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.
I>>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.
EP>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional
Это синтетика.
I>>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для EP>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания.
Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где
1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд
2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику
Здравствуйте, Ikemefula, Вы писали:
EP>>>>Без проблем. I>>>Не верю EP>>Мне всё равно, в корутины ты тоже не верил I>Если точнее, ты отрицал и продолжаешь отрицать наличие проблем из за внедрения короутин.
Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой".
EP>>>>Расшифруй. I>>>Очень просто — для ленивого кода производительность это сильно второстепенный показатель. EP>>Аргументы? I>Ленивость, если отбросить твои любимые массивы, есть это отказ от "тянем всё целиком и долго-долго считаем" в пользу "грузими кусочками", "считаем кусочками". I>Т.е. сознательно вводим задержки по времени. I>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки ! I>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки ! I>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.
Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие.
Про время выполнения например это не верно например в случае бесконечных списков
I>>>Бидирекшинал это свойство источника данных, а не твоей мульки на бусте.
EP>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional I> Это синтетика.
Random Access это синтетика?
I>>>Если ты хочешь это оспорить, валяй, сделай мне бидирекшинал вариант для EP>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания. I>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где I>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд I>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику
В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг.
Здравствуйте, Serginio1, Вы писали:
_>>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется. S> Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.
А что не так с Питоном? ) Он у нас позволяет очень удобно писать очень медленный код. Соответственно в тех случаях, когда подобное быстродействие приемлемо (например для скриптов), абсолютно логично использовать именно его. Так же как ты скажем используешь медленный 1C для всяких там бухгалтерий и т.п.
S> Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.
S>В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.
Здравствуйте, Ikemefula, Вы писали:
_>>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется. I>Ну да, сначала 3-5 лет нарабатывать квалификацию и вырабатывать условные рефлексы, одевая штаны через голову, а потом всё просто — норма. I>Самое интересное, что среди плюсовиков крайне мало людей, которые умеют писать и быстрый и удобный и стабильный код. Я бы сказал случаи единичные. I>Сейчас найм внятных плюсовиков это сумасшедший головняк для HR, хуже наверное только найм всякой экзотики или какого лиспа.
Ну да, чудес не бывает и за всё надо платить. По счастью в России (ну или во всяком случае в Москве ) это пока не особо тяжёлая проблема.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Если точнее, ты отрицал и продолжаешь отрицать наличие проблем из за внедрения короутин.
EP>Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой".
Ты ври да не завирайся. Разговор был про две основных вещи
1 нереэнтерабельный код
2 эвентлуп
В _частном_ случае может работать и это всё что ты показал. То есть,
1 ты прибил логику гвоздями к эвентлупу, тот самый ресайз и тд и тд
2 в твоем коде не было нереэнтерабельного кода
Потому и работает
В общем случае ты вводишь в софтину ничем не ограниченую реэнтерабельность из за кооперативной многозадачности.
Объясняю в очередной раз
void нереэнтерабельнаяФункция() {
var xOld = x;
x = newX();
...
stream.read(); // здесь будет переключение из за короутины
// и где нибудь еще возможен повторый вызов нереэнтерабельнаяФункция()
...
x = xOld();
}
Ну и про эвентлуп всё в силе — должен быть или явный вызов или возврат, в противном случае короутина может спокойно перекидывать управление туда-сюда минуя эвентлуп. Это же элементарно — вариант вида "бесконечный ping-pong" ровно ничем не отличается от "while(true){}". Всегда должен быть явный вызов продолжения основной нитки. Если бы ты не прибил гвоздями код к эвентлупу, увидел бы это самостоятельно.
I>>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки ! I>>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки ! I>>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки.
EP>Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие.
Это и есть общий случай.
EP>Про время выполнения например это не верно например в случае бесконечных списков
Ровно наоборот, обрабатывать бесконечный список ленивым кодом элементарно.
EP>>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional I>> Это синтетика. EP>Random Access это синтетика?
Ленивая работа с массивами это синтетика.
EP>>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания. I>>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где I>>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд I>>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику
EP>В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг.
Алё — производительность вычисления одного кусочка не меняется. Производительность вычисления всей цепочки — дерградирует на порядки. Ради того и оптимизуется. Издержки ленивого кода в пересчете на одну порцию ничтожны. Пару виртуальных вызовов что бы получить следующую порцию данных.
А вот на синтетике вида "посчитаем сумму элементов массива ленивым способом" будет разница может и в 100 раз. Это ни о чем.
Здравствуйте, Ikemefula, Вы писали:
I>>>Если точнее, ты отрицал и продолжаешь отрицать наличие проблем из за внедрения короутин. EP>>Ты отрицал что пример заработает, даже смотря на рабочий код, а потом что-то щёлкнуло и "ой". I>Ты ври да не завирайся. Разговор был про две основных вещи I>1 нереэнтерабельный код I>2 эвентлуп I>В _частном_ случае может работать и это всё что ты показал.
Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
, по ней вниз/вверх.
I>>>Отложеные — значит результат вернется не сейчас а в удобное время в будущем. То есть на ровном месте — задержка. Опаньки ! I>>>По частям — значит мы не считаём всё, а берем небольшую порцию которой минимально хватат для продолжения. Опаньки ! I>>>То есть, отсюда следует, что мы сознательно увеличиваем время выполнения цепочки на порядки. EP>>Ты думаешь о каком-то частном случае, и пытаешься распространить его свойства на другие. I>Это и есть общий случай. EP>>Про время выполнения например это не верно например в случае бесконечных списков I>Ровно наоборот, обрабатывать бесконечный список ленивым кодом элементарно.
А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке.
EP>>>>Например данные в обычном массиве — то есть Random Access. После применения фильтра-предиката можно получить bidirectional I>>> Это синтетика. EP>>Random Access это синтетика? I>Ленивая работа с массивами это синтетика.
С чего это вдруг?
Например выше по теме как раз об этом и говорили.
EP>>>>Это дешёвая демагогия. Мол ты гриб, если хочешь оспорить — то докажи истинность ложного высказывания. I>>>Демагогия это когда ты хочешь ленивость на массиве делать. А вообще ленивость предназначена к использованию там, где I>>>1 нет возможности хранить всё в памяти, это основной случай- примерно 99% случаев — бд, фс, ос, сеть и тд и тд I>>>2 слишком долго считать весь объем, но данные легко влезают в память, — остальные 1% случаев, включая твою любимую синтетику EP>>В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг. I>Алё — производительность вычисления одного кусочка не меняется.
В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста.
Здравствуйте, alex_public, Вы писали:
I>>Сейчас найм внятных плюсовиков это сумасшедший головняк для HR, хуже наверное только найм всякой экзотики или какого лиспа.
_>Ну да, чудес не бывает и за всё надо платить. По счастью в России (ну или во всяком случае в Москве ) это пока не особо тяжёлая проблема.
В москве все немного необычно, мерить по ней остальные регионы как минимум странно.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Ты ври да не завирайся. Разговор был про две основных вещи I>>1 нереэнтерабельный код I>>2 эвентлуп I>>В _частном_ случае может работать и это всё что ты показал.
EP>Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
Вот-вот, смотри сам — ты явно прибил короутины к эвентлупу. Про реэнтерабельность — там же.
Раз уж ты яростно не согласен про эвентлуп и тд, покажи на _моём_ примере, как сделать так, что бы код не морозил эвентлуп
Еще раз и внятно:
var coPing = coroutine(ping);
var coPong = coroutine(pong);
function ping () { while(true) { coPong(); } }
function pong () { while(true) { coPing(); } }
coPing();
setInterval(function(){ console.log('UI is alive'); }, 1000); // пока работает таймер, эвентлуп жив. Но сюда мы никогда не попадём
Ты хорошо понимаешь, что здесь происходит ? Вычислительная модель 1 к 1 с вин32 однопоточным UI приложением
EP>А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке.
Задержки — есть. Каждый элемент бесконечного списка ты обрабатываешь за чуть большее вермя, чем с энергичным списком. В итоге, скажем, если крутить оба варианта в течение недели-месяца-года, то энергичный вариант `уедет` гораздо дальше ленивого.
Т.е. та самая разница, которой можно пренебречь в единичном случае, может сыграть роль в случае большого количества итераций.
Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы.
EP>>>Random Access это синтетика? I>>Ленивая работа с массивами это синтетика.
EP>С чего это вдруг?
Я уже объяснил. Частота встречаемости задач вот такая, не в твою пользу. Теоретически есть, а практически в миллион раз чаще встречается работа с конскими данными(файловая система) или по своей сути адски медленными(бд, сеть и тд).
EP>>>В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг. I>>Алё — производительность вычисления одного кусочка не меняется.
EP>В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста.
Из за ленивости — не теряется. Т.е. этим можно пренебречь
Здравствуйте, Ikemefula, Вы писали:
EP>>Врёшь. Ты сам предложил конкретную тему примера и верищал про подвигший UI, и не надо приплетать сюда реэнтрабельность. Вот одна из веток
Ты говорил про говорил про повисший UI — его нет.
I>ты явно прибил короутины к эвентлупу.
Где? В event-loop дёргается обычный handler, который дёргался бы при любой реализации, даже без корутин
EP>>А я не говорил что трудно, это опять твои фантазии. Ты сказал что в каких-то случаях может появится задержка, и мол поэтому нам на время выполнения всё равно. Бесконечные списки — это контрпример, тут нет никаких задержек по сравнению с энергичным кодом, так как он вообще загнётся на бесконечном списке. I>Задержки — есть. Каждый элемент бесконечного списка ты обрабатываешь за чуть большее вермя, чем с энергичным списком.
1. Ещё раз, энергичного бесконечного списка нет.
2. Даже если представить что был бы — откуда задержки в ленивом варианте?
EP>>>>В обоих случаях производительность важна, и это не вторичный показатель. Молодец, сам себе опроверг. I>>>Алё — производительность вычисления одного кусочка не меняется. EP>>В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста. I>Из за ленивости — не теряется.
Естественно, теряется из-за тормозов в языках, а не из-за самой ленивости, с этого всё и началось.
, по ней вниз/вверх. I>>Вот-вот, смотри сам - EP>Ты говорил про говорил про повисший UI — его нет.
В частном случае будет работать.
I>>ты явно прибил короутины к эвентлупу. EP>Где? В event-loop дёргается обычный handler, который дёргался бы при любой реализации, даже без корутин
Ты нарисуй на бумажке весь флоу и посмотришь, каким чудом выполняется эвентлуп. Вариантов немного — или явный вызов или явный возврат. Собтсвенно раз ты скипнул мой вариант кода, пудозреваю такой вопрос для тебя слишком сложен
I>>Задержки — есть. Каждый элемент бесконечного списка ты обрабатываешь за чуть большее вермя, чем с энергичным списком.
EP>1. Ещё раз, энергичного бесконечного списка нет.
Точнее, дождаться окончания генерации или обработки невозможно. Прервать и/или проверить, склько сгенерировали/проверили можно очень даже легко.
EP>2. Даже если представить что был бы — откуда задержки в ленивом варианте?
Из-за самой ленивости, способ итерирования другой, с управлением извне.
EP>>>В том числе теряется и она — на тормозных языках, с чего и начался разговор. Но у тебя как всегда недержание контекста. I>>Из за ленивости — не теряется.
EP>Естественно, теряется из-за тормозов в языках, а не из-за самой ленивости, с этого всё и началось.
Из за ленивости. Это всегда дополнительные приседания. самый быстрый цыкл это while(true) {}
Если хочешь дозировать и управлять, то дозирование и управление требуют ресурсов процессора-памяти-времени.
Здравствуйте, Ikemefula, Вы писали:
I>Раз уж ты яростно не согласен про эвентлуп и тд, покажи на _моём_ примере, как сделать так, что бы код не морозил эвентлуп I>Еще раз и внятно: I>
I>
I>Ты хорошо понимаешь, что здесь происходит ? Вычислительная модель 1 к 1 с вин32 однопоточным UI приложением
Опять демагогия, и попытка уйти от ответственности. Там пример был совершенно другой, ты говорил что код вида:
Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение.
Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать.
I>Т.е. та самая разница, которой можно пренебречь в единичном случае, может сыграть роль в случае большого количества итераций. I>Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы.
Так при меньшем вычислении на один элемент разница ещё заметнее, если она конечно бы была
Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение. EP>Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать.
Правильно. У тебя _почти_ так и происходит, только раскрутка происходит при _непосредтсвенном_ участии эвентлупа. Т.е. в одном месте ты с помощью эвентлупа накапливаешь данные, а потом возвращаешь управление снова тому же эвентлупу. И там и там — явно.
Хочешь внятно выступить — смотри мой пример с пинг-понгом. В ём всё что надо видно
В кратце это означает, что возможности для применения короутин ничтожно малы — только там, где есть 100% контроля.
I>>Т.е. та самая разница, которой можно пренебречь в единичном случае, может сыграть роль в случае большого количества итераций. I>>Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы. EP>Так при меньшем вычислении на один элемент разница ещё заметнее, если она конечно бы была
Здравствуйте, Ikemefula, Вы писали:
I>Собтсвенно раз ты скипнул мой вариант кода, пудозреваю такой вопрос для тебя слишком сложен
Ты уже опустился ниже плинтуса, докопался до того что я не ответил на твои правки задним числом
EP>>2. Даже если представить что был бы — откуда задержки в ленивом варианте? I>Из-за самой ленивости, способ итерирования другой, с управлением извне.
Например в случае transformed (а-ля map) способ итерирования один и тот же
Это синтетика.
) это пока не особо тяжёлая проблема.
