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

Сообщение Re[101]: Тормознутость и кривость linq от 03.05.2016 6:01

Изменено 03.05.2016 6:43 Serginio1

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

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


_>>>Это всё слова. А тесты показывают другое. Да и не только тесты, но и примеры настоящих специалистов (а не форумных теоретиков), имеющих дело с сильно нагруженными системами.

S>> Тесты как раз без AsNoTracking итд. Нужно смотреть где тормоза, а потом их обсуждать. Ты же берешь тесты и делаешь выводы без всякого профилирования, и говоришь о настоящих специалистах?. Есть другие тесты и с другими результатами.

_>Какое ещё профилирование? Ты так и не понял смысл проведённых тестов? ) Мы не пытаемся измерить какие-то абсолютные цифры и потом сделать их анализ. Мы делаем два отдельных теста на одной и той же ORM, один в режиме sql строк и второй в режиме linq. И соответственно разница между ними априори будет равна накладным расходам от применения linq. Это очевидно даже ребёнку, без всяких профайлеров.

Угу. Я не знаю сколько в этих тестах например занимает компиляция запроса, отображение запроса на модель и тд. Что бы все твои домыслы не были голословными.
S>> Стоит так же сравнить CompiledQuery
S>>http://stackoverflow.com/questions/4932594/when-should-i-use-a-compiledquery

_>Ну так сравни, в чём проблема? Все исходники тестов в наличие. Это мне сложно с ними работать, т.к. у меня не развёрнут стек от MS. А ты же вроде как раз им пользуешься, значит для тебя проблем быть не должно. )

Доказательство домыслов должно лежать на тех, кто эти домыслы распространяет.
Re[101]: Тормознутость и кривость linq
Здравствуйте, alex_public, Вы писали:

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


_>>>Это всё слова. А тесты показывают другое. Да и не только тесты, но и примеры настоящих специалистов (а не форумных теоретиков), имеющих дело с сильно нагруженными системами.

S>> Тесты как раз без AsNoTracking итд. Нужно смотреть где тормоза, а потом их обсуждать. Ты же берешь тесты и делаешь выводы без всякого профилирования, и говоришь о настоящих специалистах?. Есть другие тесты и с другими результатами.

_>Какое ещё профилирование? Ты так и не понял смысл проведённых тестов? ) Мы не пытаемся измерить какие-то абсолютные цифры и потом сделать их анализ. Мы делаем два отдельных теста на одной и той же ORM, один в режиме sql строк и второй в режиме linq. И соответственно разница между ними априори будет равна накладным расходам от применения linq. Это очевидно даже ребёнку, без всяких профайлеров.

Угу. Я не знаю сколько в этих тестах например занимает компиляция запроса, отображение запроса на модель и тд. Что бы все твои домыслы не были голословными.
S>> Стоит так же сравнить CompiledQuery
S>>http://stackoverflow.com/questions/4932594/when-should-i-use-a-compiledquery

_>Ну так сравни, в чём проблема? Все исходники тестов в наличие. Это мне сложно с ними работать, т.к. у меня не развёрнут стек от MS. А ты же вроде как раз им пользуешься, значит для тебя проблем быть не должно. )

Бремя доказательство домыслов должно лежать на тех, кто эти домыслы распространяет.
Возьмем для примера тесты на которые ты ссылаешься. Чисто технически нет никаких проблем сделать динамически ручной алгоритм.
После выполнения первого запроса можно закэшировать как запрос к базе, так и отображение результата на модель.
Можно использовать DynamicMethods генерируемый через ILGenerator, деревья выражений, а также через компиляцию кода с использованием рослина (Scripting API). То есть основные затраты будут только на первый запрос.
Но большинство запросов именно динамические. Там нужна другая схема