Сообщение Re[91]: Тормознутость и кривость linq от 01.05.2016 19:27
Изменено 01.05.2016 19:30 alex_public
Здравствуйте, netch80, Вы писали:
_>>Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq.
N>Тогда ты очень плохо держишь исходную тему в процессе обсуждения. Потому что уже после 2-3 последующих сообщений этот исходный пример ушёл куда-то погулять, а вы радостно переключились на сложности формирования SQL.
Ну т.к. моим самым изначальным тезисом (с которого и началось всё это длинное обсуждение) было что-то вроде "все ORM на базе Linq тормознутые", то данные отклонения от темы тоже вполне попадали в рамки.
N>Пример как раз достаточно разумный, если исходить из практики. Хранимка тут как раз малосущественна, такой же запрос с case внутри (неважно, явном или нет) можно было послать и напрямую с клиента (да, я видел такое в реальности). Различие именно в том, чьи затраты меньше — локального генератора (linq2db или аналога) или сервера (сможет ли сервер, например, сразу сэкономить на входе на ветке, которая при компиляции SQL запроса для него константа false).
Ты похоже вообще не прочитал его статью. ))) Как раз дело в том, что сервер компилирует хранимку/запрос один раз при первом использование и дальше использует готовое. Причём проводит оптимизацию. Так вот в данном случае будет получаться оптимизированное решение под одно значение параметра, которое будет сильно тормозить при другом значение параметра. Что бы сделать в данном случае оптимизированное решение на хранимках достаточно было бы просто написать две отдельных хранимки (для null и для нормального значения) и вызывать нужную в конкретном случае. Но это как раз уже выглядит дольше и неудобнее. В отличие от случая с запросом в коде, где создание вариативного запроса записывается проще и короче чем один сложный универсальный (и при этом медленный из-за вышеописанных причин) запрос.
N>Но дальше вы тут же растеклись на что-то совсем странное. Ты вот утверждаешь, что там внутри сплошная рефлексия, а коллеги — что там expression trees. Мне тут больше непонятно, почему рефлексия такая чудовищно дорогая — миллисекунды. Но если её нет, то и дороговизны нет, а ты ничего не мерял.
http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html всё вполне себе измерено. Правда не мной, но так даже лучше (никто не будет придираться к пристрастности тестера
).
_>> Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной.
N>Запроса SQL? Тогда это в общем случае, мягко говоря, сомнительно. И есть контрпримеры для многих баз, когда вложенный select дешевле сложного join, и другие аналогичные тонкости.
Речь про конкретный пример из статьи, а не про вообще.
_>> Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
N>Ну, зачем ты перешёл на рекламу C++ в треде дотнет против явы, отдельный вопрос.
_>>Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq.
N>Тогда ты очень плохо держишь исходную тему в процессе обсуждения. Потому что уже после 2-3 последующих сообщений этот исходный пример ушёл куда-то погулять, а вы радостно переключились на сложности формирования SQL.
Ну т.к. моим самым изначальным тезисом (с которого и началось всё это длинное обсуждение) было что-то вроде "все ORM на базе Linq тормознутые", то данные отклонения от темы тоже вполне попадали в рамки.
N>Пример как раз достаточно разумный, если исходить из практики. Хранимка тут как раз малосущественна, такой же запрос с case внутри (неважно, явном или нет) можно было послать и напрямую с клиента (да, я видел такое в реальности). Различие именно в том, чьи затраты меньше — локального генератора (linq2db или аналога) или сервера (сможет ли сервер, например, сразу сэкономить на входе на ветке, которая при компиляции SQL запроса для него константа false).
Ты похоже вообще не прочитал его статью. ))) Как раз дело в том, что сервер компилирует хранимку/запрос один раз при первом использование и дальше использует готовое. Причём проводит оптимизацию. Так вот в данном случае будет получаться оптимизированное решение под одно значение параметра, которое будет сильно тормозить при другом значение параметра. Что бы сделать в данном случае оптимизированное решение на хранимках достаточно было бы просто написать две отдельных хранимки (для null и для нормального значения) и вызывать нужную в конкретном случае. Но это как раз уже выглядит дольше и неудобнее. В отличие от случая с запросом в коде, где создание вариативного запроса записывается проще и короче чем один сложный универсальный (и при этом медленный из-за вышеописанных причин) запрос.
N>Но дальше вы тут же растеклись на что-то совсем странное. Ты вот утверждаешь, что там внутри сплошная рефлексия, а коллеги — что там expression trees. Мне тут больше непонятно, почему рефлексия такая чудовищно дорогая — миллисекунды. Но если её нет, то и дороговизны нет, а ты ничего не мерял.
http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html всё вполне себе измерено. Правда не мной, но так даже лучше (никто не будет придираться к пристрастности тестера
)._>> Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной.
N>Запроса SQL? Тогда это в общем случае, мягко говоря, сомнительно. И есть контрпримеры для многих баз, когда вложенный select дешевле сложного join, и другие аналогичные тонкости.
Речь про конкретный пример из статьи, а не про вообще.
_>> Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
N>Ну, зачем ты перешёл на рекламу C++ в треде дотнет против явы, отдельный вопрос.
Re[91]: Тормознутость и кривость linq
Здравствуйте, netch80, Вы писали:
_>>Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq.
N>Тогда ты очень плохо держишь исходную тему в процессе обсуждения. Потому что уже после 2-3 последующих сообщений этот исходный пример ушёл куда-то погулять, а вы радостно переключились на сложности формирования SQL.
Ну т.к. моим самым изначальным тезисом (с которого и началось всё это длинное обсуждение) было что-то вроде "все ORM на базе Linq тормознутые", то данные отклонения от темы тоже вполне попадали в рамки.
N>Пример как раз достаточно разумный, если исходить из практики. Хранимка тут как раз малосущественна, такой же запрос с case внутри (неважно, явном или нет) можно было послать и напрямую с клиента (да, я видел такое в реальности). Различие именно в том, чьи затраты меньше — локального генератора (linq2db или аналога) или сервера (сможет ли сервер, например, сразу сэкономить на входе на ветке, которая при компиляции SQL запроса для него константа false).
Ты похоже вообще не прочитал его статью. ))) Как раз дело в том, что сервер компилирует хранимку/запрос один раз при первом использование и дальше использует готовое. Причём проводит оптимизацию. Так вот в данном случае будет получаться оптимизированное решение под одно значение параметра, которое будет сильно тормозить при другом значение параметра. Что бы сделать в данном случае оптимизированное решение на хранимках достаточно было бы просто написать две отдельных хранимки (для null и для нормального значения) и вызывать нужную в конкретном случае. Но это как раз уже выглядит длиннее и неудобнее. В отличие от случая с запросом в коде, где создание вариативного запроса записывается проще и короче чем один сложный универсальный (и при этом медленный из-за вышеописанных причин) запрос.
N>Но дальше вы тут же растеклись на что-то совсем странное. Ты вот утверждаешь, что там внутри сплошная рефлексия, а коллеги — что там expression trees. Мне тут больше непонятно, почему рефлексия такая чудовищно дорогая — миллисекунды. Но если её нет, то и дороговизны нет, а ты ничего не мерял.
http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html всё вполне себе измерено. Правда не мной, но так даже лучше (никто не будет придираться к пристрастности тестера).
_>> Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной.
N>Запроса SQL? Тогда это в общем случае, мягко говоря, сомнительно. И есть контрпримеры для многих баз, когда вложенный select дешевле сложного join, и другие аналогичные тонкости.
Речь про конкретный пример из статьи, а не про вообще.
_>> Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
N>Ну, зачем ты перешёл на рекламу C++ в треде дотнет против явы, отдельный вопрос.
А вот как раз этого и не было. Я в этой теме изначально писал только о тормозах Linq ORM и всё. Это оппоненты начали припоминать старые дискуссии и тащить сюда примеры из C++ (в стиле ну и пусть Linq тормозит слегка, но зато он может такое, чего твои C++ решения никогда не смогут).
_>>Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq.
N>Тогда ты очень плохо держишь исходную тему в процессе обсуждения. Потому что уже после 2-3 последующих сообщений этот исходный пример ушёл куда-то погулять, а вы радостно переключились на сложности формирования SQL.
Ну т.к. моим самым изначальным тезисом (с которого и началось всё это длинное обсуждение) было что-то вроде "все ORM на базе Linq тормознутые", то данные отклонения от темы тоже вполне попадали в рамки.
N>Пример как раз достаточно разумный, если исходить из практики. Хранимка тут как раз малосущественна, такой же запрос с case внутри (неважно, явном или нет) можно было послать и напрямую с клиента (да, я видел такое в реальности). Различие именно в том, чьи затраты меньше — локального генератора (linq2db или аналога) или сервера (сможет ли сервер, например, сразу сэкономить на входе на ветке, которая при компиляции SQL запроса для него константа false).
Ты похоже вообще не прочитал его статью. ))) Как раз дело в том, что сервер компилирует хранимку/запрос один раз при первом использование и дальше использует готовое. Причём проводит оптимизацию. Так вот в данном случае будет получаться оптимизированное решение под одно значение параметра, которое будет сильно тормозить при другом значение параметра. Что бы сделать в данном случае оптимизированное решение на хранимках достаточно было бы просто написать две отдельных хранимки (для null и для нормального значения) и вызывать нужную в конкретном случае. Но это как раз уже выглядит длиннее и неудобнее. В отличие от случая с запросом в коде, где создание вариативного запроса записывается проще и короче чем один сложный универсальный (и при этом медленный из-за вышеописанных причин) запрос.
N>Но дальше вы тут же растеклись на что-то совсем странное. Ты вот утверждаешь, что там внутри сплошная рефлексия, а коллеги — что там expression trees. Мне тут больше непонятно, почему рефлексия такая чудовищно дорогая — миллисекунды. Но если её нет, то и дороговизны нет, а ты ничего не мерял.
http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html всё вполне себе измерено. Правда не мной, но так даже лучше (никто не будет придираться к пристрастности тестера
)._>> Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной.
N>Запроса SQL? Тогда это в общем случае, мягко говоря, сомнительно. И есть контрпримеры для многих баз, когда вложенный select дешевле сложного join, и другие аналогичные тонкости.
Речь про конкретный пример из статьи, а не про вообще.
_>> Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
N>Ну, зачем ты перешёл на рекламу C++ в треде дотнет против явы, отдельный вопрос.
А вот как раз этого и не было. Я в этой теме изначально писал только о тормозах Linq ORM и всё. Это оппоненты начали припоминать старые дискуссии и тащить сюда примеры из C++ (в стиле ну и пусть Linq тормозит слегка, но зато он может такое, чего твои C++ решения никогда не смогут).