Сообщение Re[144]: Тормознутость и кривость linq. Compile-time EDSL DB от 06.07.2016 11:07
Изменено 06.07.2016 11:08 Evgeny.Panasyuk
Здравствуйте, artelk, Вы писали:
EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead
A>Не напрягает, что SQL текстовой?
Не напрягает, как минимум потому что мне вся эта тема с SQL и СУБД совершенно параллельна, ибо у меня нет таких задач
Если же потребуется сделать какой-нибудь опердень, то без проблем возьму готовый linq2db, либо вообще что-нибудь на гибком и лаконичном Python
A>Это ж сколько ценных тактиков на сервере тратится на парсинг!
A>А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!
Ещё один
EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead
A>Не напрягает, что SQL текстовой?
Не напрягает, как минимум потому что мне вся эта тема с SQL и СУБД совершенно параллельна, ибо у меня нет таких задач
Если же потребуется сделать какой-нибудь опердень, то без проблем возьму готовый linq2db, либо вообще что-нибудь на гибком и лаконичном Python
A>Это ж сколько ценных тактиков на сервере тратится на парсинг!
A>А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!
Ещё один
Re[144]: Тормознутость и кривость linq. Compile-time EDSL DB
Здравствуйте, artelk, Вы писали:
EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead
A>Не напрягает, что SQL текстовой?
Не напрягает, как минимум потому что мне вся эта тема с SQL и СУБД совершенно параллельна, ибо у меня нет таких задач
Если же потребуется сделать какой-нибудь опердень, то без проблем возьму готовый linq2db, либо вообще что-нибудь на гибком и лаконичном Python
A>Это ж сколько ценных тактиков на сервере тратится на парсинг!
A>А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!
Ещё один передёргиватель
EP>>Никакой benchmark не нужен, так как результрующий ассемблерный код в обоих вариантах идентичен, с точностью до идентификаторов — то есть истинный zero overhead
A>Не напрягает, что SQL текстовой?
Не напрягает, как минимум потому что мне вся эта тема с SQL и СУБД совершенно параллельна, ибо у меня нет таких задач
Если же потребуется сделать какой-нибудь опердень, то без проблем возьму готовый linq2db, либо вообще что-нибудь на гибком и лаконичном Python
A>Это ж сколько ценных тактиков на сервере тратится на парсинг!
A>А еще СУБД статистику ведет, план запроса подбирает и многое другое сомнительное делает, что, в теории, можно было бы в компайл-тайм задать или вычислить — вот тут и надо бы пооптимизировать!
Ещё один передёргиватель