Потихоньку начинаю ковырять LINQ, но возникают очень скептичные мысли по этому поводу. Насколько сильно это все тормозит???  Может у кого-то есть какие-то статьи, может кто-то сам тестил?Очень уж интересно, да и не верится что-то, что все так хорошо: как говорится, если где-то нашли, то в чем-то потеряли!  
Чтоб не получилось как с nHibernate: у меня знакомые на серьезной конторе отказались, сказав, что сильно все тормозит при большой базе!!!
  
P. S. Прикольный ресурс накопал(все доступно и протсо)
http://blogs.gotdotnet.ru/personal/eisernw...a9-2871726a2d45

ну почему все гладко ?
вот меня мучает вопрос почему нельзя делать запрос на две базы
http://forum.vingrad.ru/forum/topic-211604.html
т.е. если бы я использовал ADO, sql server выдал бы мне сразу результат, а тут я вынужден сделать подзапросы их результаты к примеру .ToList() а потом только два полученных IEnumerable можно использовать в нужном запросе и сразу возникает вопрос а если два подзапроса имеют большой объём данных, это же надо все получить загрузить в память    в случае с ADO этим занят SQL Server и возращает только результат
вообщем как то странно

Это сообщение отредактировал(а) namespace - 19.5.2008, 22:48

Протсо если это все работает в разы тормознутее, то...это все конечно красиво, но думаю что не нужно!  

Wizard_Memfis, если тебя интересует Linq to SQL, то для SQL Server он работает даже быстрее, чем ADO.NET за счёт предварительной оптимизации запросов...

Добавлено через 10 минут и 8 секунд
Ну и ссылки:
http://dotnet.org.za/hiltong/archive/2008/...iderations.aspx
http://www.sidarok.com/web/blog/content/20...erformance.html


Скорее всего твои знакомые не осилили nHibernate, не сумели, так сказать, правильно им воспользоваться...

To source777:
Спасибо за ссылки, именно это искал!
  
P. S. А насчет друзей, может быть  

LinqToObjects работает довольно быстро (вобщем сравнимо со скоростью обычного перебора). Есть только 3 исключения. Это методы OrderBy, GrouypBy и Join. Они все заставляют немедленно выбрать весь список, а не обрабатывать его поэлементно.

А LinqToSQL?Есть по нем какая-то инфа?Может при большой базе лучше обычным способом? 

Ты слышал про такую вещь как закон дырявых абстракций? Так вот этот закон утверждает, что если пользователь абстракции не понимает как она устроена, то он с большой вероятностью рано или поздно попадёт в дыру этой абстракции... Что приведёт к экспотенциальному снижению всех показателей. 
Следствие из этого закона такое: если у тебя руки кривые, а изучать ты ничего не хочешь, то тебя никакие абстракции не спасут. В обратной ситуации ты можешь использовать любую абстракцию для повышения совокупной производительности... И чем масштабнее будет задача(или больше БД), тем больший выигрыш в производительности можно будет получить...

Насколько я помню, есть всем известная вешь:
Ниодин уровень абстракции не добавляет производительность!  

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

Т.е. вы хотите сказать что программа написанная на Яве будет быстрее программы написанной на С++? Можно пример реально работающей программы? Просьба действительно работающее приложение, а не синтетический тест. Я верю что за счет динамической компиляции можно получить большую оптимизацию каких-то алгоритмов. Хотелось бы увидеть оконное приложение, которое бы потребляло меньше ресурсов и быстрее (субъективно для пользователя) программы на дельфи или С++.

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

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

P. S. вы случаем на яве не программировали?

P.P.S. Пользовался недолго клиентом Sparc, написанном на очень абстрактной яве. Какое увеличение производительности я получил? Зато я получил потребление памяти на уровне 100 мб. Для сравнения квип, написаный на куда менее абстрактном дельфи сейчас заниает 17 мегабайт оперативной памяти.

Это сообщение отредактировал(а) zloyden - 21.5.2008, 14:52

Непонятно почему вообще появилось предположение что LINQ to SQL медленнее чем ADO.NET. На самом деле он быстрее, даже на простых запросах. Возьмите и померяйте.
http://blog.microsoft-j.net/2008/04/16/Lin...impleQuery.aspx

Да я вообще то не говорил про Linq to sql. Я про linq говорил в целом. А с Ado сравнивать толку нет. Работа идет по другому.Надо сравнивать с другими ORM технологиями. Для пример NHibernate. Но Linq MS продукт, так что...

Veitmen, какой смысл говорить о производительности LINQ в целом? Затраты на операции над запросами в LINQ в на пару порядков меньше чем задержки сети и выборки данных. NHibernate если и выиграет у LINQ to NHibernate пару миллисекунд, то пользователь этого не заметит. А LINQ to SQL, судя по гуглу, работает с той же скоростью, что и NHibernate.

Хы. Читайте все посты. Не то я говорил совсем.


Тема такая. Подразумевается вообще LINQ в вопросе я думаю. 


Хм, дайте ссылку где это написано. Я если честно не знал...

Veitmen, да вот хотя бы: http://www.mbeller.de/2007/12/performance-...tween-linq.html

У меня была одна простенькая база. Сначала я ее работал с ADO.NET, затем на Linq. Визуально разницы в работе не видно.
Linq на первый взгляд кажется удобным инструментом. У меня есть, подозрение, что можно даже объединить в одном DataContext "живую" базу с "посторонними объектами", чего нельзя было сделать в одном DataSource (imho).
Возможная потеря производительности на уровне 10% не считается критичной (иначе бы все писале на асме или С). К тому же, на уровне баз данных такая разница не суть проблема для неопытного программиста навроде меня. Я могу и больше!   без всякого нового инструментария

А можно сходный вопрос?

Начал колупать LINQ, наткнулся на утверждение:
"Линк запросы компилируются. "
Быстродействие хранимок по сравнению с обычными запросами, написанными в коде в обычном ADO.NET основано на том, что хранимки тоже предварительно компилируются.

Значит ли это, что теперь скорость выполнения запроса при вызове хранимой процедуры (в том же линке) примерно равна скорости аналогичного запроса, написанного в коде с помощью линк-технологии?

И да, и нет.
Скомпилированный LINQ-запрос дает выгоду в том плане, что в рантайм не нужно каждый раз парсить последовательность вызовов LINQ-методов для формирования expression tree. Таким образом, конечный SQL запрос формируется быстрее. О компилированных запросах можно почитать здесь: http://linqinaction.net/blogs/jwooley/arch...ed-queries.aspx. О том, на что тратятся ресурсы при формировании Sql-запроса в Linq to Sql (иными словами - о Linq pipeline), можно посмотреть видео здесь: http://linqinaction.net/blogs/jwooley/arch...ed-queries.aspx (вообще полезная видюшка: там и помимо linq pipeline есть интересная информация). Сравнение производительности скомпилированных и нескомпилированных запросов можно найти здесь: http://blogs.msdn.com/ricom/archive/2008/0...t-solution.aspx (это 13-й пост из серии, посвященной производительности linq to sql; советую ознакомиться и с другими частями).
Теперь про хранимые процедуры. Раньше хранимые процедуры имели существенное преимущество, т. к. при их создании формировался приблизительный план выполнения, а при запуске формировался и кэшировался фактический план. Однако, во-первых, судя по информации BOL, от предварительного плана для хранимок отказались, а во-вторых, теперь план выполнения кэшируется не только для хранимок, но и для любых запросов:

Хотя остается еще преимущество хранимок в плане производительности за счет того, что они из себе представляют скомпилированный код, а не сырой текст (в случае передачи sql запроса), который нужно парсить. Однако, как отмечается, в этой статье, которая направлена на то, чтобы развеять миф о превосходстве хранимок над сырыми sql-запросами, с компиляцией не все так просто:

Кроме того, существует такая проблема, как recompiling. Например, если создали новый индекс, который может повлиять на эффективность выполнения хранимки, она должна быть перекомпилирована. И на этом пути есть немало подводных камней...
Интересно, что в списке преимуществ хранимых процедур Sql Server 2005 о производительности нет ни слова:

Неспроста это...

Таким образом, отвечая на вопрос "отличается ли производительность скомпилированных linq to sql запросов и хранимых процедур", можно подытожить, что компиляция linq to sql запросов приближает их к скорости выполнения сырого sql (который, например, передается в SqlCommand в ADO.NET), минимизируя затраты на формирования sql из linq. А так как, в свою очередь, производительность sql запросов в современных версиях Sql Server сопоставима с производительностью хранимых процедур, то существенной разницы в скорости выполнения скомпилированных linq to sql запросов и хранимых процедур быть не должно.

P. S. Sql Server для меня пока не более, чем хобби. Так что все вышеизложенное - imho. Поправьте, если не прав.
PP. S. А вообще, было бы неплохо пригласить сюда кого-нибудь из раздела Sql Server, дабы подтвердили/опровергли информацию о хранимках.

Это сообщение отредактировал(а) Idsa - 30.7.2008, 23:42

Ну во всяком случае я сделал вывод о том, что все это чуть медленнее чем сырые запросы... Спасибо  Idsa

Но зато насколько удобнее...
Да и закон Мура нас лентяев уже который десяток лет выручает 

Насчет удобнее я пока не решил. В принципе я уже настолько привык писать хранимки на скл... Практически любой сложности... в скл у меня обычно вся логика, в нете только привязка к контролам...
Безусловно майкрософтовскую генерацию классов использовать удобнее, чем с помощью самодельной утилиты шлепающей в стиле ADO.NET c дальнейшей подпилкой... но вот в плане селектов и пр., возможно ограничусь вызовом готовых процедур через LINQ.
Хотя возможно и не ограничусь...  

Модератор: познавательную дискуссию о foreach вынес сюда.

Кто-то проводил тесты?