Re[86]: Тормознутость и кривость linq
От: alex_public  
Дата: 27.04.16 14:52
Оценка: :))
Здравствуйте, gandjustas, Вы писали:

_>>Примеры на гитхабе полностью компилируемые и исполняемые (собственно было бы странно иначе). Я проверял сам и может проверить любой наш читатель. Так что тут ты уже заврался сверх меры, причём на глазах у всех.
G>Ты предлагаешь тебе на слово поверить? Сделай тесты на этой библиотеке, докажи что не свистишь, заодно и проверим быстродействие.

Ну не хочешь верить, возьми уже сам и попробуй скомпилировать и запустить. В чём проблема то? ) Никаких зависимостей там нет (и библиотека сама только в виде заголовочный файлов, если не подключать настоящие СУБД, а ограничиться MockDB), достаточно тупо компилятора C++ и командной строки.

_>>Я вроде как вполне ясно написал уже раз десять. Запрос будет существенно отличаться от хранимки и будет оптимальным. При условие что его пишет не альтернативно одарённый человек. Хотя бы потому, что оптимальная запись является короче того страшного запроса в хранимке, с которым ты там боролся.
G>Ну так напиши этот оптимальный запрос.

В том же предыдущем сообщение он был, только чуть ниже (и виден в цитате чуть ниже в данном сообщение). У тебя какие-то проблемы со зрением? )

G>>>Я по-разному пробовал, результат не меняется.
_>>Совсем разучился уже со своим Linq. ))) string query="select ... where "+ship_date?"ship_date=@ship_date":"ship_date is null"; Заметно короче и проще твой страшной хранимки, не так ли? ) И при этом полностью оптимально с точки зрения создания планов...
G>Наконец-то, через 5 постов ты родил строку кода.
G>Надеюсь ты понял какую проблему надо решать.

Строка то всем очевидная и я её озвучил только потому, что ты признался что "Я по-разному пробовал, результат не меняется", т.е. что даже такая банальщина тебе уже не по силам. Ну так теперь, когда ты узнал как писать вменяемый код, ты понимаешь что все твои разговоры об оптимизации в той статье были бредовыми? ) Как раз из-за того что ты рассматривал только варианты хранимки vs linq.

G>Теперь задача посложнее:
G>
G>if(categoryFilter != null)
G>{
G>   products = products.Where(p => p.Category.Name.StartsWith(categoryFilter));
G>}
G>

G>Теперь от параметра не просто добавляется фильтр, а еще и делается джоин. Без параметров никаких джоинов нет.
G>Сама коллекция product может содержать быть отфильтрована и другими предикатами до фильтра по имени категории.
G>Как это сделать на склейке строк или твоей библиотеке?
G>Как родишь код, подумай что таких параметров на каждый запрос будет десяток.

Мне не очевидно из данного кода что там за join, зачем он и вообще о чём речь. Или показывай подробнее про задачу, таблицы и т.п. или просто покажи какой генерируется итоговый sql.

_>>Я тебе уже озвучил что мне требуется. ) Пример на C# (для сравнения) работающий с любой вменяемой СУБД (для Linq же это вроде не проблема, не так ли?) С SQL Server я никогда в жизни не встречался и начинать не планирую. )
G>Ты сейчас вертишься как уж на сковородке чтобы избежать прямого сравнения говноподелки с linq любыми способами.
G>Давай так:
G>1) ты вроде утверждал, что можно с помощью конфига подменить генерацию запросов в коде на C++, чтобы они работали для другой базы

Да, для этого мне надо будет подключить в код соответствующий провайдер этой СУБД (как и в linq кстати). Так вот соответствующего развёрнутого провайдера у меня на компьютере нет. Ну и чтобы ты понимал (если не в курсе), в мире C++ библиотеки распространяются в исходниках (хотя бы потому что компиляторы разные и несовместимые), а не в виде бинарника. Т.е. провайдер надо не просто скачать, а ещё и собрать. Причём для его сборки потребуются ещё и какие-то зависимости от производителя СУБД (SDK там какой-нибудь скачать или что-то в этом роде). И у меня нет ни малейшего желания разбираться как оно там делается для данной сомнительной СУБД, которая уж точно мне никогда в жизни не пригодится. )

G>То есть ты можешь взять базу northwind, перегать её в postgres, написать для нее тестовые запросы, выложить код на github.
G>А мы просто с гитхаба возьмем код, поменяем параметры чтобы тоже самое работало с SQL Server.
G>Так?
G>И ты работаешь с чем хочешь и сравнить потом можно. Так что приступай.

См. выше.
Re[87]: Тормознутость и кривость linq
От: · Великобритания  
Дата: 27.04.16 17:35
Оценка: +1
Здравствуйте, alex_public, Вы писали:
G>>Теперь задача посложнее:
G>>
G>>if(categoryFilter != null)
G>>{
G>>   products = products.Where(p => p.Category.Name.StartsWith(categoryFilter));
G>>}
G>>

G>>Теперь от параметра не просто добавляется фильтр, а еще и делается джоин. Без параметров никаких джоинов нет.
G>>Сама коллекция product может содержать быть отфильтрована и другими предикатами до фильтра по имени категории.
G>>Как это сделать на склейке строк или твоей библиотеке?
G>>Как родишь код, подумай что таких параметров на каждый запрос будет десяток.
_>Мне не очевидно из данного кода что там за join, зачем он и вообще о чём речь. Или показывай подробнее про задачу, таблицы и т.п. или просто покажи какой генерируется итоговый sql.
Плохо, что неочевидно. Показывает, что не сталкивался со сложными запросами, поэтому и считаешь что их реально генерить в compile time.
псевдокод такой примерно:
List<Product> getProducts(String categoryFilter)
{
   if(categoryFilter == null)
      return resultOfQuery(
        "SELECT * FROM Product");
   else
      return resultOfQuery(
        "SELECT * FROM Product p"+
            " INNER JOIN Category c ON(c.id=p.categoryId)"+
            " WHERE c.name LIKE '{categoryFilter}%'")
}

а теперь представь себе что таких nullable-фильтров 10 штук. Получается 1024 варианта запросов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[88]: Тормознутость и кривость linq
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 27.04.16 17:52
Оценка:
Здравствуйте, ·, Вы писали:

·>Плохо, что неочевидно. Показывает, что не сталкивался со сложными запросами, поэтому и считаешь что их реально генерить в compile time.
·>псевдокод такой примерно:
·>
·>List<Product> getProducts(String categoryFilter)
·>{
·>   if(categoryFilter == null)
·>      return resultOfQuery(
·>        "SELECT * FROM Product");
·>   else
·>      return resultOfQuery(
·>        "SELECT * FROM Product p"+
·>            " INNER JOIN Category c ON(c.id=p.categoryId)"+
·>            " WHERE c.name LIKE '{categoryFilter}%'")
·>}
·>

·>а теперь представь себе что таких nullable-фильтров 10 штук. Получается 1024 варианта запросов.

Это шутка? Даже с этим ручным закатом солнца получается банально, в стиле
   base = "SELECT * FROM Product p"
   filter = []
   if categoryFilter is not None:
      base += " INNER JOIN Category c ON(c.id=p.categoryId)"
      filter.append("c.name LIKE '{categoryFilter}%'")
   ... остальные 9 вариантов, которые могут модифицировать отдельные компоненты ...
   ## финализируем текст
   request = base + (" WHERE " if filter else "") + " AND ".join(filter)


Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.
The God is real, unless declared integer.
Re[89]: Тормознутость и кривость linq
От: · Великобритания  
Дата: 27.04.16 19:54
Оценка:
Здравствуйте, netch80, Вы писали:

N>Это шутка? Даже с этим ручным закатом солнца получается банально, в стиле
N>
N>   ... остальные 9 вариантов, которые могут модифицировать отдельные компоненты ...
N>

Ты сам шутишь, с шашкой наголо на танки. Давай-ка добавь хотя бы ещё два параметра, посмеёмся вместе:
if(categoryName != null)
{
   products = products.Where(p => p.Category.Name.StartsWith(categoryName));
}
if(categoryColor != null)
{
   products = products.Where(p => p.Category.Color == categoryColor);
}
if(categoryGroupName != null)
{
   products = products.Where(p => p.Category.Group.Name == categoryGroupName);
}


N>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.
Да к тому же ты не compile-time генерацию предложил, твой питонный код источник жутких тормозов, т.к. не обладает Нулевым Оверхедом™.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 27.04.2016 19:56 · . Предыдущая версия .
Re[90]: Тормознутость и кривость linq
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 27.04.16 20:22
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты сам шутишь, с шашкой наголо на танки.

Так вся разница пока в том, что эта шашка ещё не доросла до гаубицы.
Пару лет развития и вообще в Большую Берту превратится...

·> Давай-ка добавь хотя бы ещё два параметра, посмеёмся вместе:

Именно в этих — проблемы нет (если ты ничего не скрыл).
Просто кусок марудной работы, в которой очень легко сделать тупую ошибку.

N>>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.
·>Да к тому же ты не compile-time генерацию предложил, твой питонный код источник жутких тормозов, т.к. не обладает Нулевым Оверхедом™.

Питон — это потому, что мне легче на нём быстро формулировать. Мог быть любой другой язык.

Ты не понял другое (может, я криво объяснил). Я не верю, что компилятор сам соптимизирует это в compile time в готовые выражения — для этого он должен сгенерировать 1024 ветки. Обычно компиляторы так не поступают
Показанный код был для метагенератора исходника. (А, теперь понимаю — надо было не if categoryFilter is not None, а if generatingWith('categoryFilter') или как-то похоже.) Вот если это сгенерировано — то уже компилятору деваться некуда.

А в случае безвариантно заданного вида запроса и целевого движка — да, можно сделать такой набор шаблонов, чтобы он генерировал запрос ещё при компиляции. Но мне бы не понравился выходной бинарь с, например, 1024*12 веток кода... как-то это противоестественно. Несмотря на то, что "Нулевой Оверхед", который ты вспомнил (чьё?), похоже,таки будет.
The God is real, unless declared integer.
Re[91]: Тормознутость и кривость linq
От: · Великобритания  
Дата: 27.04.16 21:03
Оценка:
Здравствуйте, netch80, Вы писали:

N>·>Ты сам шутишь, с шашкой наголо на танки.
N>Так вся разница пока в том, что эта шашка ещё не доросла до гаубицы.
N>Пару лет развития и вообще в Большую Берту превратится...
В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.

N>·> Давай-ка добавь хотя бы ещё два параметра, посмеёмся вместе:
N>Именно в этих — проблемы нет (если ты ничего не скрыл).
N>Просто кусок марудной работы, в которой очень легко сделать тупую ошибку.
Ну собственно да, код становится страшным, нудным, трудно-тестируемым и сложным в поддержке. alex_public это и не понимает, так же как с call-site не понимал, я решил ему и это разжевать.

N>>>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.
N>·>Да к тому же ты не compile-time генерацию предложил, твой питонный код источник жутких тормозов, т.к. не обладает Нулевым Оверхедом™.
N>Питон — это потому, что мне легче на нём быстро формулировать. Мог быть любой другой язык.
Так собственно linq это и делает у себя внутрях по сути во время runtime, а alex_public говорил что это тормоза — используйте compile time.

N>Ты не понял другое (может, я криво объяснил). Я не верю, что компилятор сам соптимизирует это в compile time в готовые выражения — для этого он должен сгенерировать 1024 ветки. Обычно компиляторы так не поступают
Тут alex_public обещал в compile_time все запросы генерить, читай выше.

N>Показанный код был для метагенератора исходника. (А, теперь понимаю — надо было не if categoryFilter is not None, а if generatingWith('categoryFilter') или как-то похоже.) Вот если это сгенерировано — то уже компилятору деваться некуда.
Зачем ещё исходники генерить? Вот linq использует expression tree и генерацию runtime, как я понимаю.

N>А в случае безвариантно заданного вида запроса и целевого движка — да, можно сделать такой набор шаблонов, чтобы он генерировал запрос ещё при компиляции. Но мне бы не понравился выходной бинарь с, например, 1024*12 веток кода... как-то это противоестественно. Несмотря на то, что "Нулевой Оверхед", который ты вспомнил (чьё?), похоже,таки будет.
Ты не читаешь что-ли топик? Я ж вообще-то alex_public отвечал, например тут Тормознутость и кривость linq читай "linq привносит оверхед в рантайм" и выше по топику.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[89]: Тормознутость и кривость linq
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.04.16 21:29
Оценка:
Здравствуйте, netch80, Вы писали:

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

N>·>а теперь представь себе что таких nullable-фильтров 10 штук. Получается 1024 варианта запросов.

N>Это шутка? Даже с этим ручным закатом солнца получается банально, в стиле
N>
N>   base = "SELECT * FROM Product p"
N>   filter = []
N>   if categoryFilter is not None:
N>      base += " INNER JOIN Category c ON(c.id=p.categoryId)"
N>      filter.append("c.name LIKE '{categoryFilter}%'")
N>   ... остальные 9 вариантов, которые могут модифицировать отдельные компоненты ...
N>   ## финализируем текст
N>   request = base + (" WHERE " if filter else "") + " AND ".join(filter)
N>

Уже не получилось, ибо select *

N>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.
Вариантов больше, потому что не только фильтры, но еще и проекции разные.

Это должно было стать следующим шагом к пониманию проблемы:
// в BL
if(categoryFilter != null)
{
   products = products.Where(p => p.Category.Name.StartsWith(categoryFilter));
}

// где-то в другой единице компиляции
var viewModel = products.Select(p => new { CategoryName = p.Category.Name, ProductName = p.Name})
//и таких select еще 10 штук каждый со своей проекцией
Re[59]: Тормознутость и кривость linq
От: Ночной Смотрящий Россия  
Дата: 28.04.16 00:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду.

Ты явно не понимаешь о чем пишешь. Нет там никаких 1-10 в секунду, нагрузка сильно неравномерная. По моим прикидкам 16 лямов в месяц означают среднепиковую (т.е. среднюю в часы пик) в районе 150 страниц (не запросов, а именно страниц) в секунду.
Re[92]: Тормознутость и кривость linq
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.04.16 02:50
Оценка:
Здравствуйте, ·, Вы писали:

N>>·>Ты сам шутишь, с шашкой наголо на танки.
N>>Так вся разница пока в том, что эта шашка ещё не доросла до гаубицы.
N>>Пару лет развития и вообще в Большую Берту превратится...
·>В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.

"Ты не читаешь что-ли топик?"
Наверно, ни в чём. Во всяком случае, я не увидел реального преимущества, в случае, если эта готовая доступна и ничему не мешает.
Но я сохраняю возможность принять вариант, что есть какая-то выгода от альтернативы

·>Зачем ещё исходники генерить?

Это вопрос не ко мне

·>Ты не читаешь что-ли топик? Я ж вообще-то alex_public отвечал,

Вопрос был полуриторический. Полу- — потому что я от него точных слов "нулевой оверхед" не видел. Но при таком количестве однотонных сообщений легко и пропустить.
The God is real, unless declared integer.
Re[90]: Тормознутость и кривость linq
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.04.16 02:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Это должно было стать следующим шагом к пониманию проблемы:

И это тоже.
Вопрос ведь не в конструировании для конкретного случая — его нормальный программист осилит. Вопросов два:
1) На каком по счёту таком запросе он обломится и начнёт рисовать фреймворк?
2) Если вдруг встало требование конструировать в compile time, как он будет преодолевать комбинаторный взрыв?

Пока что "ваша" (условно) сторона просто отказывается их рассматривать. Я бы тоже отказался, но мне стало интересно, чего именно добивается коллега alex_public.
The God is real, unless declared integer.
Re[87]: Тормознутость и кривость linq
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 28.04.16 03:22
Оценка: 3 (1) +3 :)
Здравствуйте, alex_public, Вы писали:

_>Да, для этого мне надо будет подключить в код соответствующий провайдер этой СУБД (как и в linq кстати). Так вот соответствующего развёрнутого провайдера у меня на компьютере нет. Ну и чтобы ты понимал (если не в курсе), в мире C++ библиотеки распространяются в исходниках (хотя бы потому что компиляторы разные и несовместимые), а не в виде бинарника. Т.е. провайдер надо не просто скачать, а ещё и собрать. Причём для его сборки потребуются ещё и какие-то зависимости от производителя СУБД (SDK там какой-нибудь скачать или что-то в этом роде). И у меня нет ни малейшего желания разбираться как оно там делается для данной сомнительной СУБД, которая уж точно мне никогда в жизни не пригодится. )

Ты только что выложил в готовом виде целую пачку аргументов сторонникам дотнета и Linq.
Наверняка это обидно — защищаешь-то ровно противоположную позицию.
The God is real, unless declared integer.
Re[89]: Тормознутость и кривость linq
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 28.04.16 07:23
Оценка:
Здравствуйте, netch80, Вы писали:

N> base = "SELECT * FROM Product p"
N> filter = []
N> if categoryFilter is not None:
N> base += " INNER JOIN Category c ON(c.id=p.categoryId)"
N> filter.append("c.name LIKE '{categoryFilter}%'")
N> ... остальные 9 вариантов, которые могут модифицировать отдельные компоненты ...
N> ## финализируем текст
N> request = base + (" WHERE " if filter else "") + " AND ".join(filter)
N>[/code]

N>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.

Во во начинаем склейку строк без типизации и интеллисение. Я сам в 1С от этого страдаю, особенно когда запросы на десяток страниц. В Linq же это делается все легко и непринужденно.
и солнце б утром не вставало, когда бы не было меня
Отредактировано 28.04.2016 7:58 Serginio1 . Предыдущая версия .
Re[85]: Тормознутость и кривость linq
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.04.16 07:42
Оценка:
Здравствуйте, netch80, Вы писали:
N>У них есть своя специфика, но, насколько я понял доступные тексты стандартов, алгоритм вида "все апострофы удвоить и вокруг результата нарисовать по одному апострофу; поставить впереди N или U&, если надо" обязан сработать чуть более чем всегда.
Дело не в этом — понятное дело, что сам ескейпинг — это не рокет сайенс. Иначе бы до сих пор никакие провайдеры никаких СУБД бы не были написаны.
Речь о том, что надо внимательно следить за статусом данных. Склейка строк — это прямой путь в ад. Потому что клеить надо вот так "...where StartDate >= " + EscapeDate(startDate), а не вот так "...where StartDate >= '" + startDate.toString()+ "'". Обычно провайдеры данных делают это неявно — используешь в запросе параметры, позиционные либо именованные, и потом отдаёшь туда значения этих параметров. А движок уже разбирается, что на что заменить.
Ну так вот с этим подходом количество проблем стремительно возрастает, как только в запрос приходит хоть какая-то динамика.
Потому что у нас в зависимости от входных данных может строиться разный SQL с разным количеством параметров, и надо не забыть передать значения для тех, которые нужны, и не передать для тех, которые не вошли. "обычные" провайдеры под это не заточены.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[93]: Тормознутость и кривость linq
От: · Великобритания  
Дата: 28.04.16 09:09
Оценка: +1
Здравствуйте, netch80, Вы писали:

N>·>В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.
N>"Ты не читаешь что-ли топик?"
N>Наверно, ни в чём. Во всяком случае, я не увидел реального преимущества, в случае, если эта готовая доступна и ничему не мешает.
N>Но я сохраняю возможность принять вариант, что есть какая-то выгода от альтернативы
linq-подобные системы бы не стали так популярны, если бы выгоды не было... Вот меня и удивило, что некоторые выгоду видеть не хотят (не могут?), мол, склеим всё что надо сами ("Совсем разучился уже со своим Linq
Автор: alex_public
Дата: 26.04.16
"), а на шаг вперёд не видят — даже код с простенькими тремя nullable параметрами выражаются довольно хитровывернутой логикой склейки.

N>·>Ты не читаешь что-ли топик? Я ж вообще-то alex_public отвечал,
N>Вопрос был полуриторический. Полу- — потому что я от него точных слов "нулевой оверхед" не видел. Но при таком количестве однотонных сообщений легко и пропустить.
Да вот пожалуйста, погляди, посмейся: его пассажи "нулевой оверхед" и "можно всё сделать во время компиляции"
Автор: alex_public
Дата: 19.03.16
. Что любопытно — сообщение с двумя плюсами. Не он один заблуждается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[89]: Тормознутость и кривость linq
От: alex_public  
Дата: 28.04.16 10:57
Оценка:
Здравствуйте, netch80, Вы писали:

N>Сразу дисклеймер: нет, я не поддерживаю позицию alex_public, что это всё лучше делать так вручную — хотя бы потому, что я банально ленив (той ленью, которая достоинство программиста), и в первую очередь побежал бы за готовым средством. Но и рассказ про 1024 варианта, мягко говоря, неадекватен.

Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq. Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной. Автор статьи никак не мог этого осознать, пока ему не продемонстрировали этот самый запрос. Только отсюда он и появился, а не из каких-то идей писать всё руками.

P.S. Хотя в случае C# и желания максимальной производительности скорее всего только вариант голых строк и подходит. Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
Re[90]: Тормознутость и кривость linq
От: alex_public  
Дата: 28.04.16 11:10
Оценка:
Здравствуйте, ·, Вы писали:

·>Ты сам шутишь, с шашкой наголо на танки. Давай-ка добавь хотя бы ещё два параметра, посмеёмся вместе:
·>
·>if(categoryName != null)
·>{
·>   products = products.Where(p => p.Category.Name.StartsWith(categoryName));
·>}
·>if(categoryColor != null)
·>{
·>   products = products.Where(p => p.Category.Color == categoryColor);
·>}
·>if(categoryGroupName != null)
·>{
·>   products = products.Where(p => p.Category.Group.Name == categoryGroupName);
·>}
·>


Ну так и в чём собственно проблема? ) Тебе трудно поставить один if? ) Количество таблиц то не является динамической величиной... )))
Re[92]: Тормознутость и кривость linq
От: alex_public  
Дата: 28.04.16 11:22
Оценка:
Здравствуйте, ·, Вы писали:

·>В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.

Ну вот на SO в начале использовали Linq, а потом выкинули его в помойку в пользу использования голых строк. Наверное там ничего не имеющие непрофессионалы сидят, да? ))) В отличие от многочисленных экспертов-теоретиков с нашего форума. )))

N>>Питон — это потому, что мне легче на нём быстро формулировать. Мог быть любой другой язык.
·>Так собственно linq это и делает у себя внутрях по сути во время runtime, а alex_public говорил что это тормоза — используйте compile time.

Ничего подобного. Linq делает не это. Точнее не только это. В начале он анализирует (через тормозную рефлексию) выражение и генерирует из него код склейки и только потом запускает собственно этот код. Причём как раз этот анализ занимает во много раз больше времени, чем собственно склейка строк. И именно оттуда и идут тормоза.

N>>Ты не понял другое (может, я криво объяснил). Я не верю, что компилятор сам соптимизирует это в compile time в готовые выражения — для этого он должен сгенерировать 1024 ветки. Обычно компиляторы так не поступают
·>Тут alex_public обещал в compile_time все запросы генерить, читай выше.

О, ещё один не умеющий читать. Уже раз сто повторялось что во время компиляции генерируются не непосредственно запросы (как такое вообще можно сделать, если в них обычно входят данные полученные от пользователя?), а код склейки соответствующих строк. Т.е. за нулевой оверхед принимается код на голых строках (с их склейкой). Конечно приятнее когда корректность sql кода проверяется во время компиляции, как делает Linq. Но при этом он привносит кучу дополнительного оверхеда. Но есть решения, которые позволяют жить и без оверхеда и со статической проверкой sql.

N>>А в случае безвариантно заданного вида запроса и целевого движка — да, можно сделать такой набор шаблонов, чтобы он генерировал запрос ещё при компиляции. Но мне бы не понравился выходной бинарь с, например, 1024*12 веток кода... как-то это противоестественно. Несмотря на то, что "Нулевой Оверхед", который ты вспомнил (чьё?), похоже,таки будет.
·>Ты не читаешь что-ли топик? Я ж вообще-то alex_public отвечал, например тут Тормознутость и кривость linq читай "linq привносит оверхед в рантайм" и выше по топику.

Не читаешь топик похоже как раз ты. )))
Re[60]: Тормознутость и кривость linq
От: alex_public  
Дата: 28.04.16 11:25
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

_>>16 миллионов запросов в месяц — это всего лишь порядка 1-10 (в зависимости от времени суток) запросов в секунду.
НС>Ты явно не понимаешь о чем пишешь. Нет там никаких 1-10 в секунду, нагрузка сильно неравномерная. По моим прикидкам 16 лямов в месяц означают среднепиковую (т.е. среднюю в часы пик) в районе 150 страниц (не запросов, а именно страниц) в секунду.

Что-то у тебя странной с арифметикой. ) Даже если предположить, что "час пик" продолжается не более одного часа, а во всё остальное время у нас нагрузка ровно 0 (чего в принципе не может быть), то уже получится более 16 миллионов в месяц.
Re[91]: Тормознутость и кривость linq
От: · Великобритания  
Дата: 28.04.16 11:29
Оценка:
Здравствуйте, alex_public, Вы писали:

_>·>Ты сам шутишь, с шашкой наголо на танки. Давай-ка добавь хотя бы ещё два параметра, посмеёмся вместе:
_>·>
_>·>if(categoryName != null)
_>·>{
_>·>   products = products.Where(p => p.Category.Name.StartsWith(categoryName));
_>·>}
_>·>if(categoryColor != null)
_>·>{
_>·>   products = products.Where(p => p.Category.Color == categoryColor);
_>·>}
_>·>if(categoryGroupName != null)
_>·>{
_>·>   products = products.Where(p => p.Category.Group.Name == categoryGroupName);
_>·>}
_>·>


_>Ну так и в чём собственно проблема? ) Тебе трудно поставить один if? ) Количество таблиц то не является динамической величиной... )))
Тебе похоже не трудно, давай тогда код склейки в студию. Ждём, надеемся.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[88]: Тормознутость и кривость linq
От: alex_public  
Дата: 28.04.16 11:30
Оценка: :))) :)
Здравствуйте, netch80, Вы писали:

N>Ты только что выложил в готовом виде целую пачку аргументов сторонникам дотнета и Linq.
N>Наверняка это обидно — защищаешь-то ровно противоположную позицию.

Ну так это же следствие не технологии, а ситуации на рынке. Т.е. если бы написание компилятора для C# было бы реально интересно кому-то кроме MS и данный продукт стал бы популярным, то все те же проблемы встали бы в полный рост и при распространение .net библиотек.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.