Здравствуйте, Ikemefula, Вы писали:
_>>Если использовать sqlpp11, то это будет выглядеть так: _>>
_>>auto F=[](auto& q, optional<int> v) {if(v) q.where.add(Table.value==*v);};
_>>
_>>Да, это естественно уже динамика, но с полной статической проверкой типов и при этом по сути не вносящая накладных расходов (относительно соответствующего кода на голых sql строках, который мы считаем минимальный базис). I>У тебя стало быть лямбда вызывается в компайл-тайм ? Эта лямбда, на секундочку, патчит запрос. Насколько качественно sqlpp работает с деревьями выражений, не ясно. Быстро не значит качественно.
Почему во время компиляции? )Это же динамический запрос и соответственно лямбда отрабатывает в рантайме, как и в примере с linq.
А что ты подразумеваешь под "некачественной" работой с деревьями выражений? )
Здравствуйте, Ikemefula, Вы писали:
_>>Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. ) I>Ты наверное не понял, но IT ошибся в твою пользу Влияние сети и бд в этих замерах было минимальным !
Ну каким же оно было минимальным, если общее время запроса было в 3 раза больше чем в обсуждаемых ранее тестах? ) Хотя конечно же теоретически можно предположить и другой вариант, что сеть у него была идеальная, просто БД была запущена на Atom'e... ))) Но что-то мне это кажется сомнительным, не говоря уже о том, что подобный вариант уже совсем не хорошо говорил бы об этих тестах.
Re[149]: Тормознутость и кривость linq. Compile-time EDSL DB
_>Почему во время компиляции? )Это же динамический запрос и соответственно лямбда отрабатывает в рантайме, как и в примере с linq.
_>А что ты подразумеваешь под "некачественной" работой с деревьями выражений? )
А можно поподробнее. Сейчас изучаю C++. В Linq не совсем лябды. Там деревья выражений которые формируются в рантайме на их основе создаются лямбды и компилируются. https://habrahabr.ru/post/181065/
Комментарии поясняют что происходит. Сначала делается дерево выражений, в котором происходит обращение к сортируемому полю. Затем из дерева выражений создается лямбда. Далее конструируется метод сортировки, способный принять лямбду. И, в конце концов, этот метод динамически запускается на выполнение.
При этом статические (неизменяемые ET) могут кэшироваться.
Здравствуйте, alex_public, Вы писали:
I>>Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?
_>Это как раз важно. А вот упомянутые тобой вещи — это вообще смешные задачи на фоне работы выполняемой БД. Ты сам то хоть пробовал замерять время преобразования из/в json на современном гигагерцовом процесссоре? ))) Там будут цифры за пределами всего обсуждаемого тут. )))
Считать нужно весь веб-стек. Ты бы попробовал эту часть замерять ? На слово ведь никому не веришь
_>У тебя изначально не верный подход к анализу вредности накладных расходов. Правильный подход такой: фиксируем и нагрузку и время отклика и дальше смотрим насколько меньше денег на железо нам можно будет потратить, в случае устранения данных накладных расходов.
Я про такой подход все время говорю, а вот ты почему то хочешь замерить только ту часть, где формируется sql неопределенного качества.
Весь веб-стек ест очень много.
Здравствуйте, alex_public, Вы писали:
_>>>Хыхы, ты похоже пропустил всё обсуждение. Данные вопросы уже подробно обсасывались прямо в данной темке. Там было продемонстрировано и как это тривиально реализуется на sqlpp11 и почему подход linq сомнителен. I>>Ты не показал, как на sqlpp склеивается два разных AST. Собтсвенно, об этом тебя попросили практически все.
_>Что такое "склейка двух разных AST"? Ты имеешь в виду что-то вроде использования одного уже записанного запроса в роли подзапроса в другом или что? Если именно это, то подобных примеров полно прямо в папке "примеры" библиотечки. )
Там ничего такого нет. Ты выдумал. Все что умеет библиотечка — тупо натягивать синтаксис. Страктуру запросов ни один из коннекторов не меняет. Такое возможно только теоретически.
_>>>P.S. Могу дать ссылки на соответствующие сообщения в данной темке. Хотя странно это всё конечно, потому как вот прямо за сообщением с обсуждаемым исходником реализации на sqlpp11 идёт твоё сообщение (хотя и не про это), так что по идее ты не мог его не видеть... I>>Набор ифов можешь оставить себе. Флажковое программирование закончилось еще в семидесятых.
_>Вообще то как раз в случае linq были показаны примеры как с if'ми. Собственно от них не уйти никак. )
Намекаешь, что ты приводил примеры linq с if'ами на с++ ? А ты умеешь врать, однако.
Здравствуйте, alex_public, Вы писали:
I>>1 В высоконагруженых приложениях применяется, в т.ч., тот же более медленный Dapper и это не является проблемой I>>2 В энтерпрайз типичные запросы строятся динамически и их тысячи I>>3 в веб приложениях бОльшую часть времени сервер висит на ожидании ответа базы. I>>Везде, см пп. 1-3 издержки веб-стека много больше издержек на OR/M. I>>Итак, что это за "другие задачи" ?
_>Любые задачи в которых велика доля быстрых запросов в БД и при этом общая нагрузка тоже достаточно велика (скажем чтобы экономия в 30% процессорного времени сервера приложений выливалась в десятки килобаксов).
Кеширование, полагаю, надо выключить ?
Re[149]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Если использовать sqlpp11, то это будет выглядеть так: _>>>
_>>>auto F=[](auto& q, optional<int> v) {if(v) q.where.add(Table.value==*v);};
_>>>
_>>>Да, это естественно уже динамика, но с полной статической проверкой типов и при этом по сути не вносящая накладных расходов (относительно соответствующего кода на голых sql строках, который мы считаем минимальный базис). I>>У тебя стало быть лямбда вызывается в компайл-тайм ? Эта лямбда, на секундочку, патчит запрос. Насколько качественно sqlpp работает с деревьями выражений, не ясно. Быстро не значит качественно.
_>Почему во время компиляции? )Это же динамический запрос и соответственно лямбда отрабатывает в рантайме, как и в примере с linq.
Ты определись, одно из двух
"не вносящая накладных расходов"
"лямбда отрабатывает в рантайме"
Если второе, то это, мягко говоря, слив.
_>А что ты подразумеваешь под "некачественной" работой с деревьями выражений? )
То и значит — sqlpp не умеет ничего тобой заявленого. Это факт. Трансформация запроса возможна только теоретически, если ктото возьмется писать специальный коннектор.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Если ты сделал свои выводы на основание предположения, что 1000000 — это число запросов в тесте, то твои выводы не верны вследствие не верности изначального предположения. ) I>>Ты наверное не понял, но IT ошибся в твою пользу Влияние сети и бд в этих замерах было минимальным !
_>Ну каким же оно было минимальным, если общее время запроса было в 3 раза больше чем в обсуждаемых ранее тестах? )
Сам подумай, что больше, X/1000 или X/10000 ? X это в основном время БД и сети.
> Хотя конечно же теоретически можно предположить и другой вариант, что сеть у него была идеальная, просто БД была запущена на Atom'e... ))) Но что-то мне это кажется сомнительным, не говоря уже о том, что подобный вариант уже совсем не хорошо говорил бы об этих тестах.
Не сеть идеальная, а влияние стети ничтожно из за особенностей рассчета.
Re[143]: Тормознутость и кривость linq. Compile-time EDSL DB query proof-of-conc
А есть объяснение использованных техник и как всё это работает вместе? А то для меня это выглядит тарабарщиной, хоть и знаком с плюсами довольно давно.
Влияние сети и бд в этих замерах было минимальным !
