Подвесит UI пока будет получать все символы. Тот пример полностью опровергает это утверждение. EP>>Попытки съехать на другой пример конечно забавны, но это уже всё начинает надоедать. I>Правильно. У тебя _почти_ так и происходит, только раскрутка происходит при _непосредтсвенном_ участии эвентлупа. Т.е. в одном месте ты с помощью эвентлупа накапливаешь данные, а потом возвращаешь управление снова тому же эвентлупу. И там и там — явно.
Покажи те места в самом эвентлупе, которые появились от того что используются корутины.
I>Хочешь внятно выступить — смотри мой пример с пинг-понгом. В ём всё что надо видно
Твой новый пример это примитивная демагогия.
I>>>Т.е. та самая разница, которой можно пренебречь в единичном случае, может сыграть роль в случае большого количества итераций. I>>>Если ты конечно выполняешь свой любимый тест навроде i++, то можно и не увидеть разницы. EP>>Так при меньшем вычислении на один элемент разница ещё заметнее, если она конечно бы была I>Она и заметна и даже измерима.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Собтсвенно раз ты скипнул мой вариант кода, пудозреваю такой вопрос для тебя слишком сложен
EP>Ты уже опустился ниже плинтуса, докопался до того что я не ответил на твои правки задним числом
Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде. Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.
EP>>>2. Даже если представить что был бы — откуда задержки в ленивом варианте? I>>Из-за самой ленивости, способ итерирования другой, с управлением извне.
EP>Например в случае transformed (а-ля map) способ итерирования один и тот же
transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.
Здравствуйте, Ikemefula, Вы писали:
I>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде.
Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин
I>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.
Придумал какой-то левый отстранённый пример — PROFIT!
EP>>>>2. Даже если представить что был бы — откуда задержки в ленивом варианте? I>>>Из-за самой ленивости, способ итерирования другой, с управлением извне. EP>>Например в случае transformed (а-ля map) способ итерирования один и тот же I>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.
Попробуй найди издержки transformed в ASM, приведённом выше.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде.
EP>Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин
Твой пример слишком громоздкий, что бы на пальцах показать весь флоу. Ты сам себя запутал
I>>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом.
EP>Придумал какой-то левый отстранённый пример — PROFIT!
Этот отстранённый пример идёт красной линией через все туториалы и статьи про корутины
I>>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек.
EP>Попробуй найди издержки transformed в ASM, приведённом выше.
Если в твоей ленивости никакого смысла нет, то умный компилер может об этом догадаться. Это говорит не о том, что издержек ленивости нет, а о том что ленивость не нужна и потому не используется.
Здравствуйте, Ikemefula, Вы писали:
I>>>Может и так, не слежу за временем. Главное что ты продолжаешь отрицать участие эвентлупа в твоём собственном коде. EP>>Всё участие event-loop'а это дёрганье заданного handler'а, которые было бы и без корутин I>Твой пример слишком громоздкий, что бы на пальцах показать весь флоу. Ты сам себя запутал
пример с message pump'ом, а теперь переобуваешься — "пример слишком громоздкий"
I>Представь — стрим заснул на пол-часа, нет данных. Что будет с UI ?
I>Покажи код — мой message pump и твой getline.
I>>>Хочешь поговорить предметно — начни с чистого, бесконечного ping-pong. На примере увидишь, какой самый минимум нужен для того, что бы встраивать короутины в приложение с эвентлупом. EP>>Придумал какой-то левый отстранённый пример — PROFIT! I>Этот отстранённый пример идёт красной линией через все туториалы и статьи про корутины
Не важно где он там идёт, это пример на другую тему. Ты делал утверждение что с message-pump'ом, и getline'ом внутри корутины будет повисшее UI — пример показывает что это неверно, и ты вроде даже согласился тогда. Зачем ты сейчас включаешь демагога неясно
I>>>transform это изоляция, абстрагирование от способа итерирования. Естетсвенно, за счет дополнительных издержек. EP>>Попробуй найди издержки transformed в ASM, приведённом выше. I>Если в твоей ленивости никакого смысла нет,
Смысл в том числе в абстракции и удобстве.
I>то умный компилер может об этом догадаться.
Ты видимо не понимаешь как оно внутри устроенно — там те же самые сравнения/инкременты указателей, разница только в том что разыменование внешнего итератора выдаёт трансформированный результат. Задача компилятора — только сделать инлайн, без навороченных loop/branch graph оптимизаций.
I>Это говорит не о том, что издержек ленивости нет, а о том что ленивость не нужна и потому не используется.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется. S>> Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.
_>А что не так с Питоном? ) Он у нас позволяет очень удобно писать очень медленный код. Соответственно в тех случаях, когда подобное быстродействие приемлемо (например для скриптов), абсолютно логично использовать именно его. Так же как ты скажем используешь медленный 1C для всяких там бухгалтерий и т.п.
ERP
S>> Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.
_>Это всё не то. Нужна предкомпиляция, а не кэширование.
Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.
Кроме того я могу Linq позволяет использовать и прямые запросы. http://metanit.com/sharp/entityframework/5.1.php
S>>В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.
_>Фоновый поток для таких целей? ) Ужасы какие... Наверное ещё и с блокировками какими-нибудь? )))
Здравствуйте, Evgeny.Panasyuk, Вы писали:
I>>Хочешь внятно выступить — смотри мой пример с пинг-понгом. В ём всё что надо видно EP>Твой новый пример это примитивная демагогия.
Я и говорю, что ты хочешь только удобные для себя аргументы смотреть. С твоим кодом уже наигрались, хватит.
I>>Она и заметна и даже измерима.
EP>
Здравствуйте, Serginio1, Вы писали:
_>>Это всё не то. Нужна предкомпиляция, а не кэширование. S> Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.
А что конкретно ты подразумеваешь под динамическими запросами?
S>Кроме того я могу Linq позволяет использовать и прямые запросы. S>http://metanit.com/sharp/entityframework/5.1.php S>Часто бывает, что Linq не берет всех возможностей T-SQL, можно либо подправлять запросы, либо писать их с нуля.
Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.
_>>А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение. S>Ну да EF это недоразумение, а sqlpp11. При поиске на который 1-2 ссылки. Read Me меньше чем моя статья для 1С ников про линк. S>Вот такие они "специализированные эффективные инструменты"
Не, sqlpp11 не умеет (да и не должно уметь, т.к. это вообще другая область) кэшировать результаты запросов. Под специализированными эффективными инструментами подразумевались такие вещи как memcached. А ещё лучше просто включение соответствующей возможности прямо в СУБД, т.к. тогда не надо беспокоиться о валидности кэша.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Это всё не то. Нужна предкомпиляция, а не кэширование. S>> Я тебе уже кучу примеров давал, что есть динамические запросы и никакая предкомпиляция не спасет, на который ты кстати не соизволил ответить.
_>А что конкретно ты подразумеваешь под динамическими запросами? http://rsdn.ru/forum/philosophy/6203039.1
S>>Кроме того я могу Linq позволяет использовать и прямые запросы. S>>http://metanit.com/sharp/entityframework/5.1.php S>>Часто бывает, что Linq не берет всех возможностей T-SQL, можно либо подправлять запросы, либо писать их с нуля.
_>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно.
Если нужно выжимать все до остатка, то да приходится оптимизировать. Если производительности хватает, то выбирай, что хочешь.
Просто в Net есть огромный выбор как технологий так и инструментов.
_>>>А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение. S>>Ну да EF это недоразумение, а sqlpp11. При поиске на который 1-2 ссылки. Read Me меньше чем моя статья для 1С ников про линк. S>>Вот такие они "специализированные эффективные инструменты"
_>Не, sqlpp11 не умеет (да и не должно уметь, т.к. это вообще другая область) кэшировать результаты запросов. Под специализированными эффективными инструментами подразумевались такие вещи как memcached. А ещё лучше просто включение соответствующей возможности прямо в СУБД, т.к. тогда не надо беспокоиться о валидности кэша.
А в EF все в одном. Поэтому для 99% задач подходят не эффективные по скорости, но удобные для программирования компоненты.
и солнце б утром не вставало, когда бы не было меня
Если количество элементов в массиве определено на момент компиляции (как в твоём сообщение), то никаких динамических запросов не требуется (во всяком случае в C++ или любом другом языке с элементами метапрограммированием). Если же число элементов в массиве произвольно и известно только в момент исполнения, то действительно требуется динамическое формирование запросов. И sqlpp11 это тоже без проблем умеет (см. в конце этого https://github.com/rbock/sqlpp11/blob/master/examples/select.cpp примера). )))
_>>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно. S> Если нужно выжимать все до остатка, то да приходится оптимизировать. Если производительности хватает, то выбирай, что хочешь. S>Просто в Net есть огромный выбор как технологий так и инструментов.
Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>А что конкретно ты подразумеваешь под динамическими запросами? S>>http://rsdn.ru/forum/philosophy/6203039.1
_>Если количество элементов в массиве определено на момент компиляции (как в твоём сообщение), то никаких динамических запросов не требуется (во всяком случае в C++ или любом другом языке с элементами метапрограммированием). Если же число элементов в массиве произвольно и известно только в момент исполнения, то действительно требуется динамическое формирование запросов. И sqlpp11 это тоже без проблем умеет (см. в конце этого https://github.com/rbock/sqlpp11/blob/master/examples/select.cpp примера). )))
А оно может быть различным, как например запрос на вхождение в массив.
Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.
_>>>Ну т.е. снова возвращаемся к той же самой дилемме: или удобно и неэффективно или эффективно, но неудобно. S>> Если нужно выжимать все до остатка, то да приходится оптимизировать. Если производительности хватает, то выбирай, что хочешь. S>>Просто в Net есть огромный выбор как технологий так и инструментов.
_>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))
Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>А оно может быть различным, как например запрос на вхождение в массив. S>Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.
Ничего не понял из этой фразы. Кстати, ты сам то смотрел описание библиотеки, прежде чем задавать эти вопросы? ) Посмотри тут https://github.com/rbock/sqlpp11/wiki/Select что ты хотел. Если не найдёшь, то тогда уже спрашивай (только с более внятной формулировкой).
_>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. ))) S>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>А оно может быть различным, как например запрос на вхождение в массив. S>>Кстати а где навигационные свойства? Где запросы через несколько точек? Неговоря об отложенных загрузках навигационных свойств.
_>Ничего не понял из этой фразы. Кстати, ты сам то смотрел описание библиотеки, прежде чем задавать эти вопросы? ) Посмотри тут https://github.com/rbock/sqlpp11/wiki/Select что ты хотел. Если не найдёшь, то тогда уже спрашивай (только с более внятной формулировкой).
Это и есть понятие.Из за него в общем то и городится весь огород.
Кстати это говорит о том, что ты не читаешь моих ссылок.
Там куча примеров к доступу к объектам через навигационные свойства.
А может ты, О ужас не понимаешь примитивного C# ного кода?
Там кстати почти всё на родном русском
var qr = from Номенклатура in бд.Спр_Номенклатура
select new
{
Номенклатура.Наименование,
Номенклатура.ПолнНаименование,
Единицы = (Номенклатура.ПодчиненныеЕдиницы.Where(единица => единица.ШтрихКод.CompareTo("4") > 0)
.Select(единица =>
new
{
единица.ШтрихКод,
ОКЕИ = единица.ОКЕИ.Наименование
}
)
)
};
Я могу сразу сказать, что конечно можно самому добавить левые соединения, но это будет значительно больше кода чем как ты тут выразился про ужасные предваритеные компиляции запроса
_>>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. ))) S>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру
_>Аргументированно. )))
Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд.
Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.
Кроме того удобство в биндинге и редактировании http://metanit.com/sharp/entityframework/3.3.php
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. )))
Это заблуждение. Практически все тормозные софтины на с++ тормозят и лагают именно потому, что их разработчики считали: "Мы на с++, значит всё само быстро !!!!111расрас"
Здравствуйте, alex_public, Вы писали:
_>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код.
Представь себе, язык это не всемогутор, решает вполне конкретный набор задач. Что характерно, с++ когда то доминировал в тех областях, которые сейчас целиком на менеджед решениях. C++ полностью ушел в низкоуровневые слои. Логика вида "взять со счета и положить на другой счет" уже давно не пишется на плюсах.
>В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
Вот эта цена и есть дилемма, которой нет. Эта цена становится препятствием для многих проектов и даже целых контор.
пример с message pump'ом, а теперь переобуваешься — "пример слишком громоздкий" EP>
I>>Представь — стрим заснул на пол-часа, нет данных. Что будет с UI ?
I>>Покажи код — мой message pump и твой getline.
Ты сам видишь, что ты процитировал ? Вот мой message pump совершенно не в курсе, что надо вызвать какую то функцию для заполнения данных. Откуда твой стрим будет брать данные ? Откуда будет управление получать ?
Здравствуйте, Serginio1, Вы писали:
S> Это и есть понятие.Из за него в общем то и городится весь огород. S>Кстати это говорит о том, что ты не читаешь моих ссылок. S> Там куча примеров к доступу к объектам через навигационные свойства.
А с чего ты взял, что мне должен быть знаком термин "навигационные свойства"? ) Он не известен ни в мире SQL, ни просто в мире программирования. Так что используя такие специфические термины из какой-то там одной библиотечки одного языка, полагается пояснять их.
Ладно, так и быть, я не поленился и глянул в гугле что это хрень такая. Оказывается (судя по тому, что я прочитал) это автоматические запросы данных в соседних таблицах в случае нахождения в таблице внешних ключей. Крайне сомнительная возможность, особенно в контексте быстродействия.
S> Я могу сразу сказать, что конечно можно самому добавить левые соединения, но это будет значительно больше кода чем как ты тут выразился про ужасные предваритеные компиляции запроса
Между прочим это может быть не единственным решением. В определённых ситуациях гораздо более выгодными могут быть отдельные запросы.
S>>>Угу sqlpp11 это доказывает, что ему до EF как среднестатистическому 1С нику до С++ гуру _>>Аргументированно. ))) S> Так а где твои аргументы, сравнивая наколеночную разработку по которой нет ни статей, с минимумом упоминаний в интернете с EF огромным количеством материалов, обсуждений итд. S> Еще раз в моей статье больше примеров чем в разработке по твоей ссылке.
Да, всё правильно. ) sqlpp11 — это чья-то там мелкая наколенная разработка, а EF — это здоровенный продукт мегакорпорации. И тем забавнее, что эта наколенная штуковина является намного более быстродействующей (просто по построению) при точно таком же синтаксисе (т.е. удобстве).
S>Кроме того удобство в биндинге и редактировании S>http://metanit.com/sharp/entityframework/3.3.php
Это опять же уже не имеет никакого отношения к ORM — это уже возможности GUI библиотеки. Причём в любом языке (в C# это тоже относится не к EF, а к WinForms). И в C++ естественно тоже полно решений на эту тему, но это уже совершенно другие библиотеки.
Здравствуйте, Ikemefula, Вы писали:
_>>Ну вот фокус как раз в том, что в C++ оптимизированный код пишется с ходу, а не с помощью специальных усилий. ))) I>Это заблуждение. Практически все тормозные софтины на с++ тормозят и лагают именно потому, что их разработчики считали: "Мы на с++, значит всё само быстро !!!!111расрас"
Ну да, помимо наличие компилятора языка, требуется ещё наличие соответствующей квалификации. Нюанс в том, что даже самый крутой эксперт по C# не сможет написать одновременно красивый и быстрый код — ему обязательно понадобиться лезть в какие-то рукопашные вещи типа unsafe игр или ручного sql кода.
Здравствуйте, PM, Вы писали:
PM> Буквы не читай, сообщения пиши. Или я что-то пропустил и языки Java/C# умеют работать без JVM/CLR
PM> Почитайте на досуге как авторы LMAX героически боролись (и вроде бы продолжают бороться) с JVM — пытаясь выровнять данные по границе кэш-линии; как затюнинговать сборку мусора, чтобы система не замерзала в неподходящий момент (и перезапускать всё разв в сутки в конечном итоге)
PM> Короче, сплошной <троллейбус из буханки хлеба.jpeg>
Собственно сейчас в моде Zing JVM, там задержки не более 10ms, в основном ~100us.
Писать такое на C++... неее... проще застрелиться.
А перезапуск нужен не для gc, а чтобы на диск состояние скинуть, ибо использовать классические СУБД — теоретически невозможно.
Здравствуйте, T4r4sB, Вы писали:
TB> Расскажите мне про тормоза умных указателей. Я не понимаю. TB> Может быть потому, что я не фигачу шареды направо и налево, потому что обычно я знаю, кто у ресурса хозяин, и мне хватает уника, у которого тормозить вообще нечему.
Под умными указателями понимается всё что угодно. Unique да, просто языковая конструкция, но он и не потокобезопасный.
Если нужна передача данных между тредами — нужен shared pointer, который использует lock (mutex?) — источник непредсказуемых жутких тормозов — для low latency не годится.
