Сообщение Re[4]: EntityFramework - тормоз от 15.04.2015 12:56
Изменено 15.04.2015 12:58 Evgeny.Panasyuk
Здравствуйте, gandjustas, Вы писали:
EP>>В рамках C++ это возможно, но с заморочками, так ещё нет встроенного compile-time reflection. В рамках D и Nemerle это тоже возможно, но намного проще чем в C++. А вот в C#, насколько я вижу, это невозможно, но вполне реализуемо в качестве внешнего инструмента.
G>Я вроде писал тебе про compiled query. В статическом случае все запросы прогоняются через него.
При этом обходятся ET через runtime reflection
G>А "с заморочками" вполне можно написать плагин компилятора, который эту операцию автоматизирует. То есть все статические запросы (определенные целиком внуnри метода без ветвлений), можно превратить в статические поля, которые созданы с помощью compiled query. И будут нулевые затраты.
О чём собственно и речь, но ты почему-то говорил что это невозможно:
EP>>В рамках C++ это возможно, но с заморочками, так ещё нет встроенного compile-time reflection. В рамках D и Nemerle это тоже возможно, но намного проще чем в C++. А вот в C#, насколько я вижу, это невозможно, но вполне реализуемо в качестве внешнего инструмента.
G>Я вроде писал тебе про compiled query. В статическом случае все запросы прогоняются через него.
При этом обходятся ET через runtime reflection
G>А "с заморочками" вполне можно написать плагин компилятора, который эту операцию автоматизирует. То есть все статические запросы (определенные целиком внуnри метода без ветвлений), можно превратить в статические поля, которые созданы с помощью compiled query. И будут нулевые затраты.
О чём собственно и речь, но ты почему-то говорил что это невозможно:
G>>Ты ищешь какие-то накладные расходы в linq, хотя я тебе уже написал, что это обход expression tree, от которого ты никуда не денешься, какой бы DSL ты не создал.
Re[4]: EntityFramework - тормоз
Здравствуйте, gandjustas, Вы писали:
EP>>В рамках C++ это возможно, но с заморочками, так ещё нет встроенного compile-time reflection. В рамках D и Nemerle это тоже возможно, но намного проще чем в C++. А вот в C#, насколько я вижу, это невозможно, но вполне реализуемо в качестве внешнего инструмента.
G>Я вроде писал тебе про compiled query. В статическом случае все запросы прогоняются через него.
При этом обходятся ET через runtime reflection
G>А "с заморочками" вполне можно написать плагин компилятора, который эту операцию автоматизирует. То есть все статические запросы (определенные целиком внуnри метода без ветвлений), можно превратить в статические поля, которые созданы с помощью compiled query. И будут нулевые затраты.
О чём собственно и речь, но ты почему-то говорил что это невозможно:
EP>>В рамках C++ это возможно, но с заморочками, так ещё нет встроенного compile-time reflection. В рамках D и Nemerle это тоже возможно, но намного проще чем в C++. А вот в C#, насколько я вижу, это невозможно, но вполне реализуемо в качестве внешнего инструмента.
G>Я вроде писал тебе про compiled query. В статическом случае все запросы прогоняются через него.
При этом обходятся ET через runtime reflection
G>А "с заморочками" вполне можно написать плагин компилятора, который эту операцию автоматизирует. То есть все статические запросы (определенные целиком внуnри метода без ветвлений), можно превратить в статические поля, которые созданы с помощью compiled query. И будут нулевые затраты.
О чём собственно и речь, но ты почему-то говорил что это невозможно:
G>Ты ищешь какие-то накладные расходы в linq, хотя я тебе уже написал, что это обход expression tree, от которого ты никуда не денешься, какой бы DSL ты не создал.
G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.