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 вынес сюда.

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