Сообщение Re[34]: EntityFramework - тормоз от 19.04.2015 19:23
Изменено 19.04.2015 19:30 AK107
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я пока полагаюсь на данные озвученные
EP>Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе.
EP>Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
ну вообще здесь есть сравнение, но данные устаревшие. разница между plain sql и bltoolkit в любом случае не драматична, да и не должна быть таковой в виду сетевого ввода/вывода, даже если в СУБД все закэшировано по самый край
EP>Я пока полагаюсь на данные озвученные
Автор: gandjustas
Дата: 13.04.15
gandjustas — думаю завышать он не будет, а уж придумывать тем более. Причём, насколько я понял, он там говорил про оверхед только от обхода Expression Tree, в то время как под капотом там же не только ET обходится.Дата: 13.04.15
EP>Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе.
EP>Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
ну вообще здесь есть сравнение, но данные устаревшие. разница между plain sql и bltoolkit в любом случае не драматична, да и не должна быть таковой в виду сетевого ввода/вывода, даже если в СУБД все закэшировано по самый край
Re[34]: EntityFramework - тормоз
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Я пока полагаюсь на данные озвученные
EP>Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе.
EP>Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
ну вообще здесь есть сравнение, но данные устаревшие. разница между plain sql и bltoolkit в любом случае не драматична, да и не должна быть таковой в виду сетевого ввода/вывода, даже если в СУБД все закэшировано по самый край
еще добавлю, если мне нужны ну ооочень частые запросы (а это как правило очень быстрые запросы), я использую compiled queries, в противном случае разница в два раза в сравнение с plain sql вообще не имеет значения — такие запросы как правило занимают уже существенно больше времени сами по себе на стороне БД чем оверхед на генерацию sql. Но да, я готов платить за удобство, статическую проверку и общий подход к работе с БД как с наборами данных.
EP>Я пока полагаюсь на данные озвученные
Автор: gandjustas
Дата: 13.04.15
gandjustas — думаю завышать он не будет, а уж придумывать тем более. Причём, насколько я понял, он там говорил про оверхед только от обхода Expression Tree, в то время как под капотом там же не только ET обходится.Дата: 13.04.15
EP>Тем не менее с любопытством посмотрел бы на результаты и код замеров отдельных этапов — как минимум на одном сложном и одном простом запросе.
EP>Если оверхед действительно измеряется в микросекундах — то согласен что это вполне приемлемо, думаю даже для прилично нагруженных систем.
ну вообще здесь есть сравнение, но данные устаревшие. разница между plain sql и bltoolkit в любом случае не драматична, да и не должна быть таковой в виду сетевого ввода/вывода, даже если в СУБД все закэшировано по самый край
еще добавлю, если мне нужны ну ооочень частые запросы (а это как правило очень быстрые запросы), я использую compiled queries, в противном случае разница в два раза в сравнение с plain sql вообще не имеет значения — такие запросы как правило занимают уже существенно больше времени сами по себе на стороне БД чем оверхед на генерацию sql. Но да, я готов платить за удобство, статическую проверку и общий подход к работе с БД как с наборами данных.