Сообщение Re[13]: EntityFramework - тормоз от 14.04.2015 23:46
Изменено 14.04.2015 23:47 Evgeny.Panasyuk
Здравствуйте, gandjustas, Вы писали:
G>>>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
EP>>Вот конкретный пример: compile-time template engine
EP>>В compile-time делается анализ строки, и на основе этого генерируется определённая последовательность вызовов, результирующий ASM код получается идентичным тому, который соответствует полностью ручному оптимальному коду.
G>А при чем тут Linq? Он как раз может не имея целого запроса в одном месте собрать его по кускам. Обратная задача не нужна.
При том что ты выше говорил что формирование деревьев выражений на основе конструкций языка, с отображением на классы, и последующем построением SQL будет давать накладные расходы.
Пример же показывает что возможно делать compile-time обработку без накладных расходов. Это конечно не LINQ, но представление о стоимости compile-time процессинга вполне может дать.
G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
Дело в том что деревья выражений можно полностью обрабатывать в compile-time, точно также как и обходить методанные классов, точно также как и строить SQL запрос по этим данным — неоткуда тут взяться накладным расходам времени выполнения.
G>>>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
EP>>Вот конкретный пример: compile-time template engine
Автор: Evgeny.Panasyuk
Дата: 12.10.14
Дата: 12.10.14
EP>>В compile-time делается анализ строки, и на основе этого генерируется определённая последовательность вызовов, результирующий ASM код получается идентичным тому, который соответствует полностью ручному оптимальному коду.
G>А при чем тут Linq? Он как раз может не имея целого запроса в одном месте собрать его по кускам. Обратная задача не нужна.
При том что ты выше говорил что формирование деревьев выражений на основе конструкций языка, с отображением на классы, и последующем построением SQL будет давать накладные расходы.
Пример же показывает что возможно делать compile-time обработку без накладных расходов. Это конечно не LINQ, но представление о стоимости compile-time процессинга вполне может дать.
G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
Дело в том что деревья выражений можно полностью обрабатывать в compile-time, точно также как и обходить методанные классов, точно также как и строить SQL запрос по этим данным — неоткуда тут взяться накладным расходам времени выполнения.
Re[13]: EntityFramework - тормоз
Здравствуйте, gandjustas, Вы писали:
G>>>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
EP>>Вот конкретный пример: compile-time template engine
EP>>В compile-time делается анализ строки, и на основе этого генерируется определённая последовательность вызовов, результирующий ASM код получается идентичным тому, который соответствует полностью ручному оптимальному коду.
G>А при чем тут Linq? Он как раз может не имея целого запроса в одном месте собрать его по кускам. Обратная задача не нужна.
При том что ты выше говорил что формирование деревьев выражений на основе конструкций языка, с отображением на классы, и последующем построением SQL будет давать накладные расходы.
Пример же показывает что возможно делать compile-time обработку без накладных расходов. Это конечно не LINQ, но представление о стоимости compile-time процессинга вполне может дать.
G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
Дело в том что деревья выражений можно полностью обрабатывать в compile-time, точно также как и обходить метаданные классов, точно также как и строить SQL запрос по этим данным — неоткуда тут взяться накладным расходам времени выполнения.
G>>>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
EP>>Вот конкретный пример: compile-time template engine
Автор: Evgeny.Panasyuk
Дата: 12.10.14
Дата: 12.10.14
EP>>В compile-time делается анализ строки, и на основе этого генерируется определённая последовательность вызовов, результирующий ASM код получается идентичным тому, который соответствует полностью ручному оптимальному коду.
G>А при чем тут Linq? Он как раз может не имея целого запроса в одном месте собрать его по кускам. Обратная задача не нужна.
При том что ты выше говорил что формирование деревьев выражений на основе конструкций языка, с отображением на классы, и последующем построением SQL будет давать накладные расходы.
Пример же показывает что возможно делать compile-time обработку без накладных расходов. Это конечно не LINQ, но представление о стоимости compile-time процессинга вполне может дать.
G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.
Дело в том что деревья выражений можно полностью обрабатывать в compile-time, точно также как и обходить метаданные классов, точно также как и строить SQL запрос по этим данным — неоткуда тут взяться накладным расходам времени выполнения.