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

IT>·>Как ни странно, но всё перечисленное не уступает, а чаще лучше в мире java, особенно если ещё всякие другие jvm-языки рассмотреть.
IT>Весьма голословное утверждение. Давай посмотрим хотя бы на LINQ в .NET и благодаря ему возможность работы с БД с использованием фактически типизированного SQL.

Кстати, весьма тормознутая вещь. Вообще это решение достаточно феерично своей кривизной. Умудриться сделать проверку синтаксиса во время компиляции, но при этом строить sql строки в рантайме на базе тормознутой рефлексии — это просто нечто. )))

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

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

IT>>·>Как ни странно, но всё перечисленное не уступает, а чаще лучше в мире java, особенно если ещё всякие другие jvm-языки рассмотреть.
IT>>Весьма голословное утверждение. Давай посмотрим хотя бы на LINQ в .NET и благодаря ему возможность работы с БД с использованием фактически типизированного SQL.

_>Кстати, весьма тормознутая вещь. Вообще это решение достаточно феерично своей кривизной. Умудриться сделать проверку синтаксиса во время компиляции, но при этом строить sql строки в рантайме на базе тормознутой рефлексии — это просто нечто. )))

Зачем ты этот бред написал...

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

_>>Кстати, весьма тормознутая вещь. Вообще это решение достаточно феерично своей кривизной. Умудриться сделать проверку синтаксиса во время компиляции, но при этом строить sql строки в рантайме на базе тормознутой рефлексии — это просто нечто. )))
D>Зачем ты этот бред написал...

Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку). Вместе со всеми измерениями, оценками и т.п. (в том числе и от любителей .net), так что если не разбираешься в теме, то лучше промолчать. )

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

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

_>>>Кстати, весьма тормознутая вещь. Вообще это решение достаточно феерично своей кривизной. Умудриться сделать проверку синтаксиса во время компиляции, но при этом строить sql строки в рантайме на базе тормознутой рефлексии — это просто нечто. )))
D>>Зачем ты этот бред написал...

_>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку). Вместе со всеми измерениями, оценками и т.п. (в том числе и от любителей .net), так что если не разбираешься в теме, то лучше промолчать. )

Читал я все эти разборки. И кажется, не уверен, не ты ли постоянно С++ темплитное "решение" прокидывал?

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

D>>>Зачем ты этот бред написал...
_>>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку). Вместе со всеми измерениями, оценками и т.п. (в том числе и от любителей .net), так что если не разбираешься в теме, то лучше промолчать. )
D>Читал я все эти разборки. И кажется, не уверен, не ты ли постоянно С++ темплитное "решение" прокидывал?

Ну так а если ты в курсе, что это правда, то тогда зачем пишешь про "бред"? )

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

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

D>>>>Зачем ты этот бред написал...
_>>>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку). Вместе со всеми измерениями, оценками и т.п. (в том числе и от любителей .net), так что если не разбираешься в теме, то лучше промолчать. )
D>>Читал я все эти разборки. И кажется, не уверен, не ты ли постоянно С++ темплитное "решение" прокидывал?

_>Ну так а если ты в курсе, что это правда, то тогда зачем пишешь про "бред"? )

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

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

_>>Ну так а если ты в курсе, что это правда, то тогда зачем пишешь про "бред"? )
D>Потому что ты вбрасывал несравнимое, и да я считаю, что ты кучу мессаг тогда пробросил так и не поняв почему твое решение не релевантно и по затратах на разработку, и по качеству генерации SQL.
D>Ты так и остался со своими тиками баловаться.

Причём тут какое-то "моё решение"? ) Я выше написал про тормознутость linq для sql, что полностью подтверждено в той темке. И про что ты сейчас с чего-то сказал "бред", хотя сам оказывается видел тогда все факты. А то, что я показывал какие-то примеры реализации без подобных тормозов — это к делу не относится и я собственно об этом сейчас даже и не упоминал.

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

_>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку).

Ага, и в какой то момент твои заявления доросли до настолько феерического бреда, что собеседники просто махнули рукой.

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

_>>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку).
НС>Ага, и в какой то момент твои заявления доросли до настолько феерического бреда, что собеседники просто махнули рукой.

Бредишь как раз ты сейчас. Потому как я физически не мог бы давать (и соответственно не давал — я в отличие некоторых всегда отвечаю за свои слова) точные оценки быстродействия Linq с sql потому как не использую данный инструмент. Максимум, что я мог сказать, это какие-то общетеоретические (на базе знаний о механизме работы этого инструмента) оценки, типа "в любом случае медленнее склейки голых sql строк в силу лишних накладных расходов на тормозную рефлексию и т.п.". А точные оценки тормознутости данной технологии давали в той темке специалисты, постоянно использующие её на практике, типа gandjustas. И у меня нет никаких оснований не доверять его оценкам.

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

IT>>Весьма голословное утверждение. Давай посмотрим хотя бы на LINQ в .NET и благодаря ему возможность работы с БД с использованием фактически типизированного SQL.

_>Кстати, весьма тормознутая вещь. Вообще это решение достаточно феерично своей кривизной. Умудриться сделать проверку синтаксиса во время компиляции, но при этом строить sql строки в рантайме на базе тормознутой рефлексии — это просто нечто. )))

И снова у тебя проблемы с пониманием производительности.
1 sql строки на тормознутой рефлексии строятся много меньше времени запроса к базе. Несравнимо меньше.

2 Что касается работы с коллекциями, то здесь всё очень непросто. Нужно открывать профайлер и смотреть разницу, и ты, судя по ответам в форуме, склонен игнорировать все показания профайлера.

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

_>Причём тут какое-то "моё решение"? ) Я выше написал про тормознутость linq для sql, что полностью подтверждено в той темке.

Linq для sql томозит вовсе не из за рефлексии.

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

_>>>Вообще это всё подробно разбиралось прямо на этом форуме (могу подкинуть ссылку).
НС>>Ага, и в какой то момент твои заявления доросли до настолько феерического бреда, что собеседники просто махнули рукой.

_>Бредишь как раз ты сейчас. Потому как я физически не мог бы давать (и соответственно не давал — я в отличие некоторых всегда отвечаю за свои слова) точные оценки быстродействия Linq с sql потому как не использую данный инструмент.

Вот вот. Инструмент не используешь, точных оценок нет, но ты уверенно заявляешь о проблеме с произодительностью и указываешь что проблема именно в рефлексии в том, как linq её использует.

>Максимум, что я мог сказать, это какие-то общетеоретические (на базе знаний о механизме работы этого инструмента) оценки, типа "в любом случае медленнее склейки голых sql строк в силу лишних накладных расходов на тормозную рефлексию и т.п.". А точные оценки тормознутости данной технологии давали в той темке специалисты, постоянно использующие её на практике, типа gandjustas. И у меня нет никаких оснований не доверять его оценкам.

Прекрати врать ! gangjustas нигде не говорил, что проблема из за разницы в скорости между рефлексией и склейкой голых строк.

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

I>И снова у тебя проблемы с пониманием производительности.
I>1 sql строки на тормознутой рефлексии строятся много меньше времени запроса к базе. Несравнимо меньше.

Смотря на каких запросах и к каким базам данных. ) Т.е. в некоторых случаях это будет вообще не принципиальными цифрами, а в некоторых очень существенно.

I>2 Что касается работы с коллекциями, то здесь всё очень непросто. Нужно открывать профайлер и смотреть разницу, и ты, судя по ответам в форуме, склонен игнорировать все показания профайлера.

Про коллекции сейчас вообще никто не говорил. Хотя этот вопрос тоже обсуждался на форуме и там тоже всё было печально, если сравнивать с аналогами на C++ или D. Но мы это сейчас точно обсуждать не будем. )))

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

I>Вот вот. Инструмент не используешь, точных оценок нет, но ты уверенно заявляешь о проблеме с произодительностью и указываешь что проблема именно в рефлексии в том, как linq её использует.

Проблема не в том как используют рефлексию в linq, а в том, что её вообще используют. ))) В то время как она не нужна и можно всё сделать во время компиляции.

I>Прекрати врать ! gangjustas нигде не говорил, что проблема из за разницы в скорости между рефлексией и склейкой голых строк.

"разница в скорости между рефлексией и склейкой голых строк"? ) Это ты где такой чуши набрался? )))

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

I>>1 sql строки на тормознутой рефлексии строятся много меньше времени запроса к базе. Несравнимо меньше.

_>Смотря на каких запросах и к каким базам данных. ) Т.е. в некоторых случаях это будет вообще не принципиальными цифрами, а в некоторых очень существенно.

В некоторых, крайне редких, когда база находится тут же в памяти того же процесса.

I>>2 Что касается работы с коллекциями, то здесь всё очень непросто. Нужно открывать профайлер и смотреть разницу, и ты, судя по ответам в форуме, склонен игнорировать все показания профайлера.

_>Про коллекции сейчас вообще никто не говорил. Хотя этот вопрос тоже обсуждался на форуме и там тоже всё было печально, если сравнивать с аналогами на C++ или D. Но мы это сейчас точно обсуждать не будем. )))

Если игнорировать профайлер — все печально, да.

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

_>Проблема не в том как используют рефлексию в linq, а в том, что её вообще используют. ))) В то время как она не нужна и можно всё сделать во время компиляции.

Всё — нельзя.

I>>Прекрати врать ! gangjustas нигде не говорил, что проблема из за разницы в скорости между рефлексией и склейкой голых строк.

_>"разница в скорости между рефлексией и склейкой голых строк"? ) Это ты где такой чуши набрался? )))

Тебя процитировал

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

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

I>>Вот вот. Инструмент не используешь, точных оценок нет, но ты уверенно заявляешь о проблеме с произодительностью и указываешь что проблема именно в рефлексии в том, как linq её использует.

_>Проблема не в том как используют рефлексию в linq, а в том, что её вообще используют. ))) В то время как она не нужна и можно всё сделать во время компиляции.
Ты опять о наколеночных поделках.
Я тебе уже приводил примеры где IQueryable строится в дженерик функции. С памятью у тебя совсем плохо

http://www.albahari.com/nutshell/predicatebuilder.aspx
https://github.com/scottksmith95/LINQKit

 public  IQueryable<TEntity> НайтиПоВхождениюВНаименование<TEntity>(paramsstring[] keywords) where TEntity : СправочникПредок

        {

            var predicate = PredicateBuilder.False<TEntity>();

 

            foreach (string keyword in keywords)

            {

                string temp = keyword;

                predicate = predicate.Or(p => p.Наименование.Contains(temp));

            }

            returnthis.Set<TEntity>().AsExpandable().Where(predicate);

        }

И использовать

var бд = Константы1С.ГлобальныйКонтекст.БД;

 

            var запрос = бд.НайтиПоВхождениюВНаименование<Справочник.Номенклатура>("Linq", "Наше", "Все").Select(товар => товар.Наименование);

 

            foreach (var товар in запрос)

            {

 

                Console.WriteLine("{0} ", товар);

 

            }

Генерируется следующий запрос

SELECT

    [Extent1].[DESCR] AS [DESCR]

    FROM [dbo].[SC84] AS [Extent1]

 

    WHERE ([Extent1].[DESCR] LIKE @p__linq__0 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__1 ESCAPE N'~') 

          OR([Extent1].[DESCR] LIKE @p__linq__2 ESCAPE N'~')

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

_>>Смотря на каких запросах и к каким базам данных. ) Т.е. в некоторых случаях это будет вообще не принципиальными цифрами, а в некоторых очень существенно.
I>В некоторых, крайне редких, когда база находится тут же в памяти того же процесса.

Причём тут процесс? Это вообще неактуально. Речь о времени запроса. Например, если запрашивается что-то простенькое (добываемое прямо из индекса) или даже сложное, но в БД включено кэширование, то результат будет практически мгновенно.

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

_>>Проблема не в том как используют рефлексию в linq, а в том, что её вообще используют. ))) В то время как она не нужна и можно всё сделать во время компиляции.
I>Всё — нельзя.

Это ещё почему? ) Когда-то давно мы писали код типа db("select name from users where id="+id.to_string()). Это можно считать (на самом деле это конечно же не совсем так, но это тема уже совсем другого разговора, o необходимости sql и т.п.) за референсный пример с нулевым оверхедом. Теперь же мы хотим написать что-то вроде db(select(users.name).from(users).where(users.id==id)), чтобы sql запрос был проверен компилятором (плюс ещё несколько бонусов на тему безопасности и оптимизации под конкретные БД). Соответственно, если компилятор будет преобразовывать такой код в элементарное слияние sql строк (как в первом варианте), то можно считать, что мы получаем нулевой оверхед.

Так вот даже C++ с его убогим метапрограммированием уже умеет такое (правда ценой диких извратов внутри библиотеки, но снаружи их всё равно не видно). А уж языки типа D или Nemerle такое вообще элементарно могут.

_>>"разница в скорости между рефлексией и склейкой голых строк"? ) Это ты где такой чуши набрался? )))
I>Тебя процитировал

Враньё. ) Покажи у меня такой нелепый текст. )

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

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

_>>>Смотря на каких запросах и к каким базам данных. ) Т.е. в некоторых случаях это будет вообще не принципиальными цифрами, а в некоторых очень существенно.
I>>В некоторых, крайне редких, когда база находится тут же в памяти того же процесса.

_>Причём тут процесс? Это вообще неактуально. Речь о времени запроса. Например, если запрашивается что-то простенькое (добываемое прямо из индекса) или даже сложное, но в БД включено кэширование, то результат будет практически мгновенно.
Linq кстати поддерживает кэширование. А что касается времени выполнения, то это больше относится к локальным базам на курсорах.
На SQL обычно стараются вытащить данные по максимуму одним запросом. В том числе и пакетным, который Linq пока не поддерживает.
Так, что ты не там ищешь недостатки. В большинстве задач хватает Linq to EF. Если, что то нужно оптимизировать никто не запрещает прямой SQL. А вот твоя наколеночная поделка вообще мало кем используется.