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

_>·>В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.
_>Ну вот на SO в начале использовали Linq, а потом выкинули его в помойку в пользу использования голых строк. Наверное там ничего не имеющие непрофессионалы сидят, да? ))) В отличие от многочисленных экспертов-теоретиков с нашего форума. )))
Потому что они занимались жёсткой оптимизацией, а не потому что у linq место на помойке. История не терпит сослагательного наклонения, но могу предположить, что им бы труднее было выкатить свой первый релиз и занять рынок без linq, склейкой строк.

_>·>Тут alex_public обещал в compile_time все запросы генерить, читай выше.
_>О, ещё один не умеющий читать. Уже раз сто повторялось что во время компиляции генерируются не непосредственно запросы (как такое вообще можно сделать, если в них обычно входят данные полученные от пользователя?), а код склейки соответствующих строк. Т.е. за нулевой оверхед принимается код на голых строках (с их склейкой). Конечно приятнее когда корректность sql кода проверяется во время компиляции, как делает Linq. Но при этом он привносит кучу дополнительного оверхеда. Но есть решения, которые позволяют жить и без оверхеда и со статической проверкой sql.
Да причём тут данные. Сами данные в текст запроса не входят, в текст запроса входят bind parameter placeholders. Читать я умею, похоже просто ты не понимаешь что тебе пишут. Короче, код склейки для Тормознутость и кривость linq в студию, потом продолжим.

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

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

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

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

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

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

https://habrahabr.ru/post/83169/

Вот код нашего нового создателя:

class ExpressionCreator<T> : ICreator<T>
 {
   private readonly Func<Dictionary<string, object>, T> _creator;

   public ExpressionCreator()
   {
     var type = typeof(T);
     var newExpression = Expression.New(type);
     var dictParam = Expression.Parameter(typeof(Dictionary<string, object>), "d");
     var list = new List<MemberBinding>();
     var propertyInfos = type.GetProperties(BindingFlags.Instance |
                         BindingFlags.Public |
                         BindingFlags.SetProperty);
     foreach (var propertyInfo in propertyInfos)
     {
       Expression call = Expression.Call(
                          typeof (DictionaryExtension),
                          "GetValue", new[] {propertyInfo.PropertyType},
                          new Expression[]
                            {
                              dictParam,
                              Expression.Constant(propertyInfo.Name)
                            });

       MemberBinding mb = Expression.Bind(propertyInfo.GetSetMethod(), call);
       list.Add(mb);
     }

     var ex = Expression.Lambda<Func<Dictionary<string, object>, T>>(
                                       Expression.MemberInit(newExpression, list),
                                       new[] {dictParam});
     _creator = ex.Compile();
   }
   public T Create(Dictionary<string, object> props)
   {
     return _creator(props);
   }
 }

* This source code was highlighted with Source Code Highlighter.

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


Новый создатель создается 0,01 секунду (что в 10 раз медленнее, чем у reflection, но конструктор вызывается только один раз) и тратит 0,017 секунд на создание 10000 объектов (что в 70 раз быстрее).


Кстати, если создавать объект Foo напрямую

internal class DirectCreator : ICreator<Foo>
 {
   public Foo Create(Dictionary<string, object> props)
   {
     return new Foo
     {
       Name = props.GetValue<string>("Name"),
       Value = props.GetValue<int>("Value")
     };
   }
 }

то это получается всего в два раза быстрее, чем через expressions.


Вот такие штуки позволяют нам делать Expression trees.

Там где динамические запросы обычно время вызова значительно выше времени компиляции запроса. Не забывай, что на стороне сервера такие запросы могут быть не закэшированы из-за множества вариаций

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

_>P.S. Хотя в случае C# и желания максимальной производительности скорее всего только вариант голых строк и подходит. Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
А как ты относишься к 1С? И чем C# хуже питона?
Есть языки которые решают конкретные задачи и более удобны по сравнению с другими.
Это касается не только написания, но и поддержки кода.

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

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

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

Они заменили на эквивалентный механизм — даппер.

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

Похоже, ты по прежнему уверен, что узкое место это именно сервеный код вызова базы данных

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

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

Ты совсем недавно говорил, что это достоинство, ажно доблесть. А щас подаёшь как геморрой который тебе самому не хочется пробовать

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

Обрати внимание п.4 — не только у тебя, но и у других. Когда я писал на С++, я точно так же отпихивался всеми руками и ногами от п4. И многие здесь отметившиеся когда то писали на С++ и точно так же отпихивались от п4
Собтсвенно именно потому и появились другие инструмены.

п.1..4 показывают, что твоему заказчику надо каждый раз собирать проектную команду или хотя бы одного девелопера, который соберет солюшн, пофиксит зависимости и тд и тд и тд.
Включай его ЗП в стоимость решения. За лет 5 денег наберется размером с серьезный сервер.

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

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

Дотнет, вообще говоря, и предназначался для решения тех проблем, что ты перечислил.

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

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

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

Что-то я тебя не понимаю. И Java+JVM, и C#+.NET изначально предназначены решать как раз перечисленные проблемы. Можно долго и в рамках стартовой темы, и вне её сперечаться, кто из них кому прав, а кто доктор, но получились близнецы-братья, которые всё это решают. Выходной ABI одинаков и стандартизован. Стандартна виртуальная машина, методы общения с функциями. Собирать на месте ничего не нужно, нужно лишь скачать и установить в доступное место (методы разные, но в обоих случаях известны). SDK производителя СУБД, скорее всего, уже включён (причём даже в клиническом случае Oracle, которая держит авторское право на ключевую фразу протокола, они поставляют готовые клиенты). Соревноваться с MS за написание именно компилятора C# никому не интересно (ну, с поправкой на Mono). Пишут Nemerle, не к ночи будь названо, и прочие тому подобные, а в случае Java — всякие Groovy, Kotlin, Scala и т.п., но они всё равно живут на общем рантайме и одинаковых прикладных библиотеках. Ещё что не так?

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

_>Что-то у тебя странной с арифметикой. )

Это у тебя странно что нагрузка абсолютно равномерна.

_> Даже если предположить, что "час пик" продолжается не более одного часа, а во всё остальное время у нас нагрузка ровно 0 (чего в принципе не может быть), то уже получится более 16 миллионов в месяц.

Я ж не от балды теории считаю, как ты, у меня есть статистика по сайтам аналогичной направленности. Пиковые нагрузки очень сильно отличаются от средних. Да и вообще подобные сайты меряют не запросами в секунду, а латентностью.

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

_>>Ну так и в чём собственно проблема? ) Тебе трудно поставить один if? ) Количество таблиц то не является динамической величиной... )))
·>Тебе похоже не трудно, давай тогда код склейки в студию. Ждём, надеемся.

string query="select ... from ...";
if(categoryName||categoryColor||categoryGroupName) query+=" inner join ... ON(...)";//тот самый if
query+=" where 1";
if(categoryName) query+=" and ...";
if(categoryColor) query+=" and ...";
if(categoryGroupName) query+=" and ...";

P.S. Это на чистом sql, без всяких удобных библиотечек из C++ (с ними было бы проще, т.к. без всяких строк и лишнего мусора, а просто код вида query.where.add(c.color > categoryColor); ).

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

_>>·>В смысле в аналог linq? И в чём прикол точить эту шашку два года, когда есть готовая.
_>>Ну вот на SO в начале использовали Linq, а потом выкинули его в помойку в пользу использования голых строк. Наверное там ничего не имеющие непрофессионалы сидят, да? ))) В отличие от многочисленных экспертов-теоретиков с нашего форума. )))
·>Потому что они занимались жёсткой оптимизацией, а не потому что у linq место на помойке. История не терпит сослагательного наклонения, но могу предположить, что им бы труднее было выкатить свой первый релиз и занять рынок без linq, склейкой строк.

Ну так а я о чём пишу? ) Прочитай внимательно данную тему изначально. Речь шла не о том, что linq нельзя применять нигде. А только о том, что его тормоза мешают применению там, где важна производительность. Изначально вопрос только так и ставился, так что не знаю что ты там ещё себе напридумывал.

_>>·>Тут alex_public обещал в compile_time все запросы генерить, читай выше.
_>>О, ещё один не умеющий читать. Уже раз сто повторялось что во время компиляции генерируются не непосредственно запросы (как такое вообще можно сделать, если в них обычно входят данные полученные от пользователя?), а код склейки соответствующих строк. Т.е. за нулевой оверхед принимается код на голых строках (с их склейкой). Конечно приятнее когда корректность sql кода проверяется во время компиляции, как делает Linq. Но при этом он привносит кучу дополнительного оверхеда. Но есть решения, которые позволяют жить и без оверхеда и со статической проверкой sql.
·>Да причём тут данные. Сами данные в текст запроса не входят, в текст запроса входят bind parameter placeholders. Читать я умею, похоже просто ты не понимаешь что тебе пишут. Короче, код склейки для Тормознутость и кривость linq в студию, потом продолжим.

Ты с темы то не съезжай. Ты тут от моего имени всякого бреда понаписал и потом радостно с ним же поборолся. ))) А когда тебе на это указывают, сразу же начинаешь на другие темы перескакивать. )

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

_>>>О, ещё один не умеющий читать. Уже раз сто повторялось что во время компиляции генерируются не непосредственно запросы (как такое вообще можно сделать, если в них обычно входят данные полученные от пользователя?), а код склейки соответствующих строк. Т.е. за нулевой оверхед принимается код на голых строках (с их склейкой). Конечно приятнее когда корректность sql кода проверяется во время компиляции, как делает Linq. Но при этом он привносит кучу дополнительного оверхеда. Но есть решения, которые позволяют жить и без оверхеда и со статической проверкой sql.
_>·>Да причём тут данные. Сами данные в текст запроса не входят, в текст запроса входят bind parameter placeholders. Читать я умею, похоже просто ты не понимаешь что тебе пишут. Короче, код склейки для Тормознутость и кривость linq в студию, потом продолжим.
_>Ты с темы то не съезжай. Ты тут от моего имени всякого бреда понаписал и потом радостно с ним же поборолся. ))) А когда тебе на это указывают, сразу же начинаешь на другие темы перескакивать. )
Видимо я перестал понимать в чём заключается твой тезис. Давай конкретно, проиллюстрируй что и как во время компиляции генерится для Тормознутость и кривость linq в правильных решениях без оверхеда.

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

_>>P.S. Хотя в случае C# и желания максимальной производительности скорее всего только вариант голых строк и подходит. Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
S> А как ты относишься к 1С?

Никогда не имел дел. Ни как программист, ни как пользователь (руководитель).

Слышал только что там своеобразный бухгалерский DSL с кириллическим синтаксисом.

S>И чем C# хуже питона?

Для написания скриптов C# (как и C++) очевидно хуже Питона (надеюсь не надо объяснять почему?). А для других целей я Питон особо и не использую.

S>Есть языки которые решают конкретные задачи и более удобны по сравнению с другими.
S> Это касается не только написания, но и поддержки кода.

Безусловно различные DSL'и гораздо удобнее универсальных языков в своих узких нишах.

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

_>>>Ну так и в чём собственно проблема? ) Тебе трудно поставить один if? ) Количество таблиц то не является динамической величиной... )))
_>·>Тебе похоже не трудно, давай тогда код склейки в студию. Ждём, надеемся.
_>

_>string query="select ... from ...";
_>if(categoryName||categoryColor||categoryGroupName) query+=" inner join ... ON(...)";//тот самый if
_>query+=" where 1";
_>if(categoryName) query+=" and ...";
_>if(categoryColor) query+=" and ...";
_>if(categoryGroupName) query+=" and ...";
_>

В смысле ты такой код и предлагаешь писать вместо linq?

_>P.S. Это на чистом sql, без всяких удобных библиотечек из C++ (с ними было бы проще, т.к. без всяких строк и лишнего мусора, а просто код вида query.where.add(c.color > categoryColor); ).
И где здесь compile time, нулевой оверхед и в чём отличие от linq?

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

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

Так а как там задаются запросы? )

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

Если некие тормоза не являются главными тормозами, то это не означает, что перестают быть тормозами в принципе. )))

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

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

Я не хочу пробовать с SQL Server. ) А с нужными мне СУБД у меня всё уже развёрнуто и подключение занимает одну короткую строчку текста.

I>п.1..4 показывают, что твоему заказчику надо каждый раз собирать проектную команду или хотя бы одного девелопера, который соберет солюшн, пофиксит зависимости и тд и тд и тд.
I>Включай его ЗП в стоимость решения. За лет 5 денег наберется размером с серьезный сервер.

Угу, и каждый месяц в эти 5 лет он будет подключать к новому типу РСУБД, на которую будет резко прыгать проект. ))) Ну да, ну да. )))

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

_>>Ну так это же следствие не технологии, а ситуации на рынке. Т.е. если бы написание компилятора для C# было бы реально интересно кому-то кроме MS и данный продукт стал бы популярным, то все те же проблемы встали бы в полный рост и при распространение .net библиотек.
I>Дотнет, вообще говоря, и предназначался для решения тех проблем, что ты перечислил.

Данные "проблемы" легко решает даже самый убогий и древний язычок, при наличие у него всего одной марки компилятора. )))

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

_>>Ну так это же следствие не технологии, а ситуации на рынке. Т.е. если бы написание компилятора для C# было бы реально интересно кому-то кроме MS и данный продукт стал бы популярным, то все те же проблемы встали бы в полный рост и при распространение .net библиотек.
N>Что-то я тебя не понимаю. И Java+JVM, и C#+.NET изначально предназначены решать как раз перечисленные проблемы. Можно долго и в рамках стартовой темы, и вне её сперечаться, кто из них кому прав, а кто доктор, но получились близнецы-братья, которые всё это решают. Выходной ABI одинаков и стандартизован. Стандартна виртуальная машина, методы общения с функциями.

Вот не надо путать разные вещи. Java в отличие от C# интересна не только Oracle. Причём картина с совместимостью получается полностью аналогичная. Или быть может ты хочешь сказать, что собранное для Dalvik или ART приложение заработает на обычной JVM? ) Я уже не говорю про всяческие извращения с вариациями для реального времени или микроконтроллеров.

N>Собирать на месте ничего не нужно, нужно лишь скачать и установить в доступное место (методы разные, но в обоих случаях известны). SDK производителя СУБД, скорее всего, уже включён (причём даже в клиническом случае Oracle, которая держит авторское право на ключевую фразу протокола, они поставляют готовые клиенты). Соревноваться с MS за написание именно компилятора C# никому не интересно (ну, с поправкой на Mono). Пишут Nemerle, не к ночи будь названо, и прочие тому подобные, а в случае Java — всякие Groovy, Kotlin, Scala и т.п., но они всё равно живут на общем рантайме и одинаковых прикладных библиотеках. Ещё что не так?

SDK от производителя СУБД нужен и в .net. Просто ставит его себе разработчик соответствующего провайдера для какого-нибудь там linq2db, потом собирает свою библиотечку и выкладывает бинарную сборку, для использования которой уже ничего такого не надо. Я могу сделать полностью аналогично. Просто воспользоваться данной сборкой смогут скажем только пользователи какого-нибудь gcc 5.3 и всё.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Что-то у тебя странное с арифметикой. )
НС>Это у тебя странно что нагрузка абсолютно равномерна.

Колебания в 10 раз — это по твоему называется "абсолютно равномерна"? ) Как весело. )))

_>> Даже если предположить, что "час пик" продолжается не более одного часа, а во всё остальное время у нас нагрузка ровно 0 (чего в принципе не может быть), то уже получится более 16 миллионов в месяц.
НС>Я ж не от балды теории считаю, как ты, у меня есть статистика по сайтам аналогичной направленности. Пиковые нагрузки очень сильно отличаются от средних. Да и вообще подобные сайты меряют не запросами в секунду, а латентностью.

"Очень сильно" — это сколько? ) Пока что даже если положить бесконечность (150/0), то всё равно не укладываются твои цифры. )))

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

_>>Ты с темы то не съезжай. Ты тут от моего имени всякого бреда понаписал и потом радостно с ним же поборолся. ))) А когда тебе на это указывают, сразу же начинаешь на другие темы перескакивать. )
·>Видимо я перестал понимать в чём заключается твой тезис. Давай конкретно, проиллюстрируй что и как во время компиляции генерится для Тормознутость и кривость linq в правильных решениях без оверхеда.

Изначальный мой тезис (с которого началась вся эта бесконечная дискуссия) звучал так: "ORM на базе Linq — тормоза (относительно аналогичного кода на голых sql строках)". И этот тезис был полностью доказан в теме соответствующими тестами. Дальнейшей же обсуждение свелось к двум слегка холиварным направлениям:

1. Насколько данные тормоза критичны для системы целиком. Потому как понятно, что для какого-нибудь бухгалтерского приложение накладные расходы от linq даже не почувствуются. А для систем типа SO наоборот.
2. Возможны ли какие-то решения близкие к linq (т.е. со статической проверкой sql кода, а не в виде sql строк), но без накладных расходов в рантайме. Подобное легко реализуется на любом языке с развитым метапрограммированием. И даже в языке с не самым лучшим МП (типа C++) это тоже вполне реализуемо.

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

_>>

_>>string query="select ... from ...";
_>>if(categoryName||categoryColor||categoryGroupName) query+=" inner join ... ON(...)";//тот самый if
_>>query+=" where 1";
_>>if(categoryName) query+=" and ...";
_>>if(categoryColor) query+=" and ...";
_>>if(categoryGroupName) query+=" and ...";
_>>

·>В смысле ты такой код и предлагаешь писать вместо linq?

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

_>>P.S. Это на чистом sql, без всяких удобных библиотечек из C++ (с ними было бы проще, т.к. без всяких строк и лишнего мусора, а просто код вида query.where.add(c.color > categoryColor); ).
·>И где здесь compile time, нулевой оверхед и в чём отличие от linq?

Эм, ты реально считаешь, что тормоза linq идут от процесса склейки строк? ) Да это практически мгновенные операции на фоне времени исполнения самого запроса. А вот тормоза linq (происходящие от рефлексии) вполне себе сравнимы и даже частенько превосходят время исполнения запроса.