Информация об изменениях

Сообщение Re[13]: EntityFramework - тормоз от 14.04.2015 23:46

Изменено 14.04.2015 23:47 Evgeny.Panasyuk

Здравствуйте, gandjustas, Вы писали:

G>>>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.

EP>>Вот конкретный пример: compile-time template engine
Автор: Evgeny.Panasyuk
Дата: 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
Автор: Evgeny.Panasyuk
Дата: 12.10.14

EP>>В compile-time делается анализ строки, и на основе этого генерируется определённая последовательность вызовов, результирующий ASM код получается идентичным тому, который соответствует полностью ручному оптимальному коду.
G>А при чем тут Linq? Он как раз может не имея целого запроса в одном месте собрать его по кускам. Обратная задача не нужна.

При том что ты выше говорил что формирование деревьев выражений на основе конструкций языка, с отображением на классы, и последующем построением SQL будет давать накладные расходы.
Пример же показывает что возможно делать compile-time обработку без накладных расходов. Это конечно не LINQ, но представление о стоимости compile-time процессинга вполне может дать.

G>Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.


Дело в том что деревья выражений можно полностью обрабатывать в compile-time, точно также как и обходить метаданные классов, точно также как и строить SQL запрос по этим данным — неоткуда тут взяться накладным расходам времени выполнения.