Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>И получаем запрос
SELECT foo.number FROM foo WHERE foo.id>42
НС>Жесть какая.
А надо как? На ровном месте inline view?
Или ты о проверках? Да, проверки я не реализовывал, так как демонстрируемому аспекту они не относятся, и к тому же реализованы например в sqlpp11.
НС>Это просто набор хелперных методов.
Как ты говоришь "куча говнокода"
НС>>> Потому что там написано, что хоть у C# ситаксис лямбд и лаконичнее, но в целом С++ лучше. EP>>Я не говорил "в целом лучше". НС>Ну алгоримическивыразительно лучше.
алгоримическивыразительно — да, лучше
НС>Суть та же.
Да не та же. Лучше в конкретном аспекте.
НС>>>Не надо тебе каятся, просто надо признать что все что ты тут пишешь предельно однобоко. Надо быть слепым чтобы этого не замечать. EP>>Я развеиваю мифы о C++ НС>Ага, особенно ты развеивал мифы, когда влез в топик обсуждения CodeJam в ихнем форуме и начал сравнивать С# со своим С++.
Да, в том числе. Постоянно говорят что на C++ нужно писать больше кода и т.п.
НС>влез в топик обсуждения CodeJam в ихнем форуме
Что значит в "ихнем"? Закрытый клуб?
Я например показал пример Boost, сказал что там плохо в плане организации.
Или например подсказал как лучше реализовать бинарный поиск — такая реализация сейчас и используется, несмотря на то что мой пример был на C++
Re[191]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
НС>>Это просто набор хелперных методов. EP>Как ты говоришь "куча говнокода"
Нет. Ты опять не понял или не хочешь понять разницы. Все что ты привел не имеет отношения к описанию таблиц, т.е. того что ты тут на макросах генерил. Это другой код.
НС>>Суть та же. EP>Да не та же.
Та же.
EP> Лучше в конкретном аспекте.
Но другого аспекта там и не упоминается. Так в каком аналогичном аспекте С++ хуже?
НС>>Ага, особенно ты развеивал мифы, когда влез в топик обсуждения CodeJam в ихнем форуме и начал сравнивать С# со своим С++. EP>Да, в том числе. Постоянно говорят что на C++ нужно писать больше кода и т.п.
В том топике никто подобного не говорил, там вообще С++ не обсуждали.
НС>>влез в топик обсуждения CodeJam в ихнем форуме EP>Что значит в "ихнем"? Закрытый клуб?
Это значит что никакие мифы ты не опровергал, а влез в совершенно не относящийся к этой теме разговор.
EP>Я например показал пример Boost, сказал что там плохо в плане организации.
Зачем? Обсуждали ж конкретную библиотеку, где никакого буста нет и быть не может.
Re[192]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Все что ты привел не имеет отношения к описанию таблиц, т.е. того что ты тут на макросах генерил. Это другой код.
Это может генерироваться тем же генератором что и генерирует описание таблицы.
Будет в текстовом шаблоне генератора не одна строчка на поле, а десяток — это что-то принципиально меняет с точки зрения пользователя?
EP>> Лучше в конкретном аспекте. НС>Но другого аспекта там и не упоминается.
Вообще-то упоминается — проблемы при работе с зависимостями на трёх разных OS.
НС>Так в каком аналогичном аспекте С++ хуже?
Например отсутствие модулей, внятного менеджера пакетов (работающего на всех основных OS), возможность получить порчу памяти от сторонней кривой зависимости (во избежание этого, левый код нужно выносить например в отдельный процесс).
Непосредственно по языку, например:
— сложнее синтаксис, как следствие труднее делать утилиты (хотя есть готовые библиотеки а-ля libclang). Для точного дополнения и т.п., и даже точной подсветки синтаксиса нужна модель проекта — список defines, include dirs и т.п.
— отсутствие автоматического type-erasure без заранее определённой концепции (это на тему dynamic, но немного в другом ключе)
EP>>Я например показал пример Boost, сказал что там плохо в плане организации. НС>Зачем? Обсуждали ж конкретную библиотеку, где никакого буста нет и быть не может.
Обсуждали будущую организацию community-driven библиотеки, с задачами близкими к задачам Boost, я указал на конкретную проблему которая есть с организацией в Boost, которая может быть решена в CodeJam. Собственно они эту организационную проблему и решили
Re[193]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это может генерироваться тем же генератором что и генерирует описание таблицы.
Да ради бога. Но речь про описание таблиц, без которого, в отличие от хелперов, вообще никак.
EP>>> Лучше в конкретном аспекте. НС>>Но другого аспекта там и не упоминается. EP>Вообще-то упоминается — проблемы при работе с зависимостями на трёх разных OS.
И чего? Неужели С++ хуже, чем C#?
НС>>Зачем? Обсуждали ж конкретную библиотеку, где никакого буста нет и быть не может. EP>Обсуждали будущую организацию community-driven библиотеки, с задачами близкими к задачам Boost, я указал на конкретную проблему которая есть с организацией в Boost, которая может быть решена в CodeJam.
Здравствуйте, Ночной Смотрящий, Вы писали:
EP>>Вообще-то упоминается — проблемы при работе с зависимостями на трёх разных OS.
НС>И чего? Неужели С++ хуже, чем C#?
Я перед ним извинился за 2 раза (он такого не говорил). Он за свои 100 раз извиняться не хочет.
и солнце б утром не вставало, когда бы не было меня
Re[194]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Sinclair, Вы писали:
_>>Гитхаб не репрезентативен, потому что на него не принято выкладываться целым областям индустрии. Кто-нибудь видел там выложенные исходники прошивок микроконтроллеров автомобиля, выкладываемого автоконцернами? S>Да мы там даже код прошивки от Apollo 11 видели.
Который давно не летает. А от производимого сейчас автомобиля — где?
Здравствуйте, IT, Вы писали:
IT>Ты их не видел, а у меня 2 или 3 directs — это программисты COBOL. А ещё мне довелось заниматься реверс инжениренгом с COBOL, после чего я обнаружил и идентифицировал мать всех парадигм — флажковое программирование. Flag Injection & flag dependency в полный рост.
А можно подробнее?
The God is real, unless declared integer.
Re[193]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Непосредственно по языку, например:
Непосредственно по языку — С++ это фактически три языка в одном — обычный Си, шаблоны и всё остальное. Одну и ту же задачу нужно писать принципиально разным способом в каждом из этих языков.
Вот отсюда и растут проблемы — теоретически, всё в современном мире можно сделать на С++. Практически — стоимость решения оказывается неподъёмной.
Потому и надо рассматривать не абстрактный zero overhead, а конкретный трейд-оф.
Например сервер-бд. zero overhead на сервере никак не гарантирует качественной работы БД, следовательно, производительность всего приложения индиферентна к zero overhead С++ в общем случае. Отсюда, например, сразу ясно, почему в вебе прижились тормозные с т.з. С++ языки — питон, перл, джава, дотнет и даже джаваскрипт.
Здравствуйте, netch80, Вы писали:
IT>>Ты их не видел, а у меня 2 или 3 directs — это программисты COBOL. А ещё мне довелось заниматься реверс инжениренгом с COBOL, после чего я обнаружил и идентифицировал мать всех парадигм — флажковое программирование. Flag Injection & flag dependency в полный рост.
N>А можно подробнее?
Представь язык в котором модель памяти допускает только статические данные и массивы. Нет даже стека, т.е. при вызове метода нельзя передавать параметры. Вся работа исключительно через статические массивы, бесконечные флажки и базу данных.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали: G>>Но я говорил не про кеш таблиц, а про кеш результатов запроса. Его почти нигде нет или тупо не используется, потому что нереально обеспечить его когерентность. S>Я лет 15 назад читал про semantic caching, где между клиентом и сервером вклинивалась in-memory RDBMS, способная отвечать на запросы из кэша. Там прямо была продвинутая техника анализа, которая позволяла второй запрос выполнить без обращения на сервер:... S>При этом аналогичная логика трассировала предикаты в insert, update и delete, чтобы обсолетить результаты.
Такая кэшилка очень быстро сломается на запросах вида
select * from students where lastName = 'Smith'
select * from students where lastName = 'Smith' or age = 21
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали: G>>>Но я говорил не про кеш таблиц, а про кеш результатов запроса. Его почти нигде нет или тупо не используется, потому что нереально обеспечить его когерентность. S>>Я лет 15 назад читал про semantic caching, где между клиентом и сервером вклинивалась in-memory RDBMS, способная отвечать на запросы из кэша. Там прямо была продвинутая техника анализа, которая позволяла второй запрос выполнить без обращения на сервер:... S>>При этом аналогичная логика трассировала предикаты в insert, update и delete, чтобы обсолетить результаты.
G>Такая кэшилка очень быстро сломается на запросах вида G>
G>select * from students where lastName = 'Smith'
G>select * from students where lastName = 'Smith' or age = 21
G>
Неа. Там у них всё умно было — в таком случае она начинает отдавать результат из кэша, а из сервера тем временем достаёт where age=21 and lastName != 'Smith'
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
IT>>>Ты их не видел, а у меня 2 или 3 directs — это программисты COBOL. А ещё мне довелось заниматься реверс инжениренгом с COBOL, после чего я обнаружил и идентифицировал мать всех парадигм — флажковое программирование. Flag Injection & flag dependency в полный рост. N>>А можно подробнее? IT>Представь язык в котором модель памяти допускает только статические данные и массивы. Нет даже стека, т.е. при вызове метода нельзя передавать параметры. Вся работа исключительно через статические массивы, бесконечные флажки и базу данных.
Это очень странно, потому что COBOL позволяет параметры подпрограмм (функций, методов, etc.) (вот например). Или у вас какой-то особо выдержанный в рассоле мамонт, или программисты были чокнутые.
Отсутствие стека не запрещает иметь параметры подпрограмм; классические Fortran реализации точно так же без стека отлично вызывали на любую глубину, но — каждую подпрограмму/функцию только один раз, рекурсия не допускалась.
Здравствуйте, netch80, Вы писали:
N>Это очень странно, потому что COBOL позволяет параметры подпрограмм (функций, методов, etc.) (вот например). Или у вас какой-то особо выдержанный в рассоле мамонт, или программисты были чокнутые.
Я в курсе про современный Кобол. У наших орлов не просто мамонт, а его окаменевшие результаты жизнедеятельности, помноженные на весьма своеобразные догмы, домыслы и прочие козявки в голове.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
_>>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине. I>Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
Это как раз важно. А вот упомянутые тобой вещи — это вообще смешные задачи на фоне работы выполняемой БД. Ты сам то хоть пробовал замерять время преобразования из/в json на современном гигагерцовом процесссоре? ))) Там будут цифры за пределами всего обсуждаемого тут. )))
I>То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?
У тебя изначально не верный подход к анализу вредности накладных расходов. Правильный подход такой: фиксируем и нагрузку и время отклика и дальше смотрим насколько меньше денег на железо нам можно будет потратить, в случае устранения данных накладных расходов.
I>Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.
Если уж говорить про норму (как самое распространённое) в веб'е, то уж точно будет не что-то из .Net'а, а скорее какой-нибудь там PHP. ))) Ну и да, там тоже есть множество своих ORM, естественно без всяких специальных статических языков запросов.
Здравствуйте, Ikemefula, Вы писали:
_>>Хыхы, ты похоже пропустил всё обсуждение. Данные вопросы уже подробно обсасывались прямо в данной темке. Там было продемонстрировано и как это тривиально реализуется на sqlpp11 и почему подход linq сомнителен. I>Ты не показал, как на sqlpp склеивается два разных AST. Собтсвенно, об этом тебя попросили практически все.
Что такое "склейка двух разных AST"? Ты имеешь в виду что-то вроде использования одного уже записанного запроса в роли подзапроса в другом или что? Если именно это, то подобных примеров полно прямо в папке "примеры" библиотечки. )
_>>P.S. Могу дать ссылки на соответствующие сообщения в данной темке. Хотя странно это всё конечно, потому как вот прямо за сообщением с обсуждаемым исходником реализации на sqlpp11 идёт твоё сообщение (хотя и не про это), так что по идее ты не мог его не видеть... I>Набор ифов можешь оставить себе. Флажковое программирование закончилось еще в семидесятых.
Вообще то как раз в случае linq были показаны примеры как с if'ми. Собственно от них не уйти никак. )
Здравствуйте, Ikemefula, Вы писали:
_>>Казалось бы такой произвол в измерениях странен. Но он на самом деле отражает вполне очевидный реальный факт: для одних задач использование linq по сути будет бесплатным, а для других задач использование linq будет не желательно — надо смотреть каждый конкретный случай отдельно. Непонятно только одно, почему "фанаты" linq в данной ветке так упорно спорят с этим очевидным фактом. I>Подробнее про эти "другие задачи". Что за они ? С высоконагружеными, энтерпрайз приложениями и веб-приложениям эти "другие задачи" не имеют ничего общего. I>1 В высоконагруженых приложениях применяется, в т.ч., тот же более медленный Dapper и это не является проблемой I>2 В энтерпрайз типичные запросы строятся динамически и их тысячи I>3 в веб приложениях бОльшую часть времени сервер висит на ожидании ответа базы. I>Везде, см пп. 1-3 издержки веб-стека много больше издержек на OR/M. I>Итак, что это за "другие задачи" ?
Любые задачи в которых велика доля быстрых запросов в БД и при этом общая нагрузка тоже достаточно велика (скажем чтобы экономия в 30% процессорного времени сервера приложений выливалась в десятки килобаксов).
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>У меня изначально было всего лишь одно утверждение: на некоторых типах запросов (условно говоря быстрых) накладные расходы от использования linq весьма существенны. НС>Изначально у тебя было такое утверждение: НС>
НС>Вообще это решение достаточно феерично своей кривизной.
А, ну это то само собой. Сам факт проведения анализа выражений в рантайме при реализованной проверке типов во время компиляции свидетельствует о большом архитектурном косяке. Но об этом то спора и нет — данное устройство linq общеизвестно и документировано. ))) Спор идёт о том, насколько данная кривизна влияет на конкретные цифры производительности приложений.
Здравствуйте, artelk, Вы писали:
_>>Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. ) A>Т.е. число roundtrip-ов к базе было даже меньше и влияние латентности сети было меньше? A>Так это даже усиливает мое утверждение.
Что-то у тебя какие-то проблемы с базовой арифметикой. ))) Не важно сколько раз сходили в БД, один или миллион. Важно только соотношение времени потраченного на работу linq, времени потраченного на работу БД и времени потраченного на передачу по сети между ними. Так вот проведя измерения на не самой отзывчивой удалённой машине он очевидно существенно уменьшил получаемый процент накладных расходов от linq как раз за счёт увеличения общего времени на время работы сети.
Потому что там написано, что хоть у C# ситаксис лямбд и лаконичнее, но в целом С++ лучше.
Если нам не помогут, то мы тоже никого не пощадим.
