Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > LINQ (Language-Integrated Query) > Производительность LINQ???

Автор: Wizard_Memfis 19.5.2008, 13:42

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

Автор: namespace 19.5.2008, 22:47

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

Автор: Wizard_Memfis 20.5.2008, 09:42

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

Автор: source777 20.5.2008, 12:06

Wizard_Memfis, если тебя интересует Linq to SQL, то для SQL Server он работает даже быстрее, чем ADO.NET за счёт предварительной оптимизации запросов... Добавлено через 10 минут и 8 секунд Ну и ссылки: http://dotnet.org.za/hiltong/archive/2008/02/01/why-use-linq-to-sql-part-1-performance-considerations.aspx http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-improve-your-linq-to-sql-application-performance.html Цитата(Wizard_Memfis @  19.5.2008,  13:42 ) Чтоб не получилось как с nHibernate: у меня знакомые на серьезной конторе отказались, сказав, что сильно все тормозит при большой базе!!! Скорее всего твои знакомые не осилили nHibernate, не сумели, так сказать, правильно им воспользоваться...

Автор: Wizard_Memfis 20.5.2008, 15:12

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

Автор: HalkaR 20.5.2008, 15:58

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

Автор: Wizard_Memfis 20.5.2008, 17:26

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

Автор: source777 20.5.2008, 17:55

Цитата(Wizard_Memfis @  20.5.2008,  17:26 ) А LinqToSQL?Есть по нем какая-то инфа?Может при большой базе лучше обычным способом?   Ты слышал про такую вещь как закон дырявых абстракций? Так вот этот закон утверждает, что если пользователь абстракции не понимает как она устроена, то он с большой вероятностью рано или поздно попадёт в дыру этой абстракции... Что приведёт к экспотенциальному снижению всех показателей.  Следствие из этого закона такое: если у тебя руки кривые, а изучать ты ничего не хочешь, то тебя никакие абстракции не спасут. В обратной ситуации ты можешь использовать любую абстракцию для повышения совокупной производительности... И чем масштабнее будет задача(или больше БД), тем больший выигрыш в производительности можно будет получить...

Автор: Wizard_Memfis 21.5.2008, 13:02

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

Автор: source777 21.5.2008, 14:16

Цитата(Wizard_Memfis @  21.5.2008,  13:02 ) Насколько я помню, есть всем известная вешь: Ниодин уровень абстракции не добавляет производительность! smile   Такое утверждение разве что мифом можно назвать...  Если бы оно было истинным, то все до сих пор бы перфокарты пробивали, а не писали бы на языках высокого уровня...

Автор: zloyden 21.5.2008, 14:49

Цитата(source777 @ 21.5.2008,  14:16) Такое утверждение разве что мифом можно назвать...  Если бы оно было истинным, то все до сих пор бы перфокарты пробивали, а не писали бы на языках высокого уровня... Т.е. вы хотите сказать что программа написанная на Яве будет быстрее программы написанной на С++? Можно пример реально работающей программы? Просьба действительно работающее приложение, а не синтетический тест. Я верю что за счет динамической компиляции можно получить большую оптимизацию каких-то алгоритмов. Хотелось бы увидеть оконное приложение, которое бы потребляло меньше ресурсов и быстрее (субъективно для пользователя) программы на дельфи или С++. Появление языков высокого уровня было обусловлено не ускорением работы софта, написанного на нем, а ускорением и упрощением времени разработки. Или вы будете утверждать что с тех пор производительность компьютеров не улучшилась? Пользователи железом за упрощение работы программистов(т.е. нас с вами). Увеличение абстракции не дает скорости производительности(чаще всего наоборот), но дает скорость разработки, что позволяет разрабатывать более сложные вещи в разумные сроки. P. S. вы случаем на яве не программировали? P.P.S. Пользовался недолго клиентом Sparc, написанном на очень абстрактной яве. Какое увеличение производительности я получил? Зато я получил потребление памяти на уровне 100 мб. Для сравнения квип, написаный на куда менее абстрактном дельфи сейчас заниает 17 мегабайт оперативной памяти.

Автор: PashaPash 24.5.2008, 14:18

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

Автор: Veitmen 24.5.2008, 15:18

Цитата(PashaPash @  24.5.2008,  14:18 ) Непонятно почему вообще появилось предположение что LINQ to SQL медленнее чем ADO.NET. На самом деле он быстрее, даже на простых запросах. Возьмите и померяйте. Да я вообще то не говорил про Linq to sql. Я про linq говорил в целом. А с Ado сравнивать толку нет. Работа идет по другому.Надо сравнивать с другими ORM технологиями. Для пример NHibernate. Но Linq MS продукт, так что...

Автор: PashaPash 24.5.2008, 17:13

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

Автор: Veitmen 24.5.2008, 19:05

Хы. Читайте все посты. Не то я говорил совсем. Цитата(PashaPash @  24.5.2008,  17:13 ) Veitmen, какой смысл говорить о производительности LINQ в целом? Тема такая. Подразумевается вообще LINQ в вопросе я думаю.  Цитата(PashaPash @  24.5.2008,  17:13 ) NHibernate если и выиграет у LINQ to NHibernate пару миллисекунд, то пользователь этого не заметит. А LINQ to SQL, судя по гуглу, работает с той же скоростью, что и NHibernate.  Хм, дайте ссылку где это написано. Я если честно не знал...

Автор: PashaPash 24.5.2008, 19:23

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

Автор: akizelokro 29.5.2008, 14:38

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

Автор: AleXGray 30.7.2008, 20:09

А можно сходный вопрос? Начал колупать LINQ, наткнулся на утверждение: "Линк запросы компилируются. " Быстродействие хранимок по сравнению с обычными запросами, написанными в коде в обычном ADO.NET основано на том, что хранимки тоже предварительно компилируются. Значит ли это, что теперь скорость выполнения запроса при вызове хранимой процедуры (в том же линке) примерно равна скорости аналогичного запроса, написанного в коде с помощью линк-технологии?

Автор: Idsa 30.7.2008, 23:28

Цитата(AleXGray @  31.7.2008,  00:09 ) Значит ли это, что теперь скорость выполнения запроса при вызове хранимой процедуры (в том же линке) примерно равна скорости аналогичного запроса, написанного в коде с помощью линк-технологии?  И да, и нет. Скомпилированный LINQ-запрос дает выгоду в том плане, что в рантайм не нужно каждый раз парсить последовательность вызовов LINQ-методов для формирования expression tree. Таким образом, конечный SQL запрос формируется быстрее. О компилированных запросах можно почитать здесь: http://linqinaction.net/blogs/jwooley/archive/2007/09/04/linq-to-sql-compiled-queries.aspx. О том, на что тратятся ресурсы при формировании Sql-запроса в Linq to Sql (иными словами - о Linq pipeline), можно посмотреть видео здесь: http://linqinaction.net/blogs/jwooley/archive/2007/09/04/linq-to-sql-compiled-queries.aspx (вообще полезная видюшка: там и помимо linq pipeline есть интересная информация). Сравнение производительности скомпилированных и нескомпилированных запросов можно найти здесь: http://blogs.msdn.com/ricom/archive/2008/01/14/performance-quiz-13-linq-to-sql-compiled-query-cost-solution.aspx (это 13-й пост из серии, посвященной производительности linq to sql; советую ознакомиться и с другими частями). Теперь про хранимые процедуры. Раньше хранимые процедуры имели существенное преимущество, т. к. при их создании формировался приблизительный план выполнения, а при запуске формировался и кэшировался фактический план. Однако, во-первых, судя по http://msdn.microsoft.com/en-us/library/aa174792.aspx, от предварительного плана для хранимок отказались, а во-вторых, теперь план выполнения кэшируется не только для хранимок, но и для любых запросов: Цитата In SQL Server version 6.5 and earlier, stored procedures were a way to partially precompile an execution plan. At the time the stored procedure was created, a partially compiled execution plan was stored in a system table. Executing a stored procedure was more efficient than executing an SQL statement because SQL Server did not have to compile an execution plan completely, it only had to finish optimizing the stored plan for the procedure. Also, the fully compiled execution plan for the stored procedure was retained in the SQL Server procedure cache, meaning that subsequent executions of the stored procedure could use the precompiled execution plan. SQL Server 2000 and SQL Server version 7.0 incorporate a number of changes to statement processing that extend many of the performance benefits of stored procedures to all SQL statements. SQL Server 2000 and SQL Server 7.0 do not save a partially compiled plan for stored procedures when they are created. A stored procedure is compiled at execution time, like any other Transact-SQL statement. SQL Server 2000 and SQL Server 7.0 retain execution plans for all SQL statements in the procedure cache, not just stored procedure execution plans. The database engine uses an efficient algorithm for comparing new Transact-SQL statements with the Transact-SQL statements of existing execution plans. If the database engine determines that a new Transact-SQL statement matches the Transact-SQL statement of an existing execution plan, it reuses the plan. This reduces the relative performance benefit of precompiling stored procedures by extending execution plan reuse to all SQL statements. Хотя остается еще преимущество хранимок в плане производительности за счет того, что они из себе представляют скомпилированный код, а не сырой текст (в случае передачи sql запроса), который нужно парсить. Однако, как отмечается, в http://www.sqlservercentral.com/articles/Editorial/63870/ статье, которая направлена на то, чтобы развеять миф о превосходстве хранимок над сырыми sql-запросами, с компиляцией не все так просто: Цитата When SQL Server executes stored procedures, any parameter values used by the procedure when it compiles are included as part of generating the query plan. If these values represent the typical ones with which the procedure is called subsequently, then the stored procedure benefits from the query plan each time it compiles and executes. If not, performance may suffer. Кроме того, существует такая проблема, как recompiling. Например, если создали новый индекс, который может повлиять на эффективность выполнения хранимки, она должна быть перекомпилирована. И на этом пути есть немало подводных камней... Интересно, что в http://technet.microsoft.com/en-us/library/ms191436.aspx преимуществ хранимых процедур Sql Server 2005 о производительности нет ни слова: Цитата The benefits of using stored procedures in SQL Server rather than Transact-SQL programs stored locally on client computers are:     * They are registered at the server.     * They can have security attributes (such as permissions) and ownership chaining, and certificates can be attached to them.       Users can be granted permission to execute a stored procedure without having to have direct permissions on the objects referenced in the procedure.     * They can enhance the security of your application.       Parameterized stored procedures can help protect your application from SQL Injection attacks. For more information see SQL Injection.     * They allow modular programming.       You can create the procedure once, and call it any number of times in your program. This can improve the maintainability of your application and allow applications to access the database in a uniform manner.     * They are named code allowing for delayed binding.       This provides a level of indirection for easy code evolution.     * They can reduce network traffic.       An operation requiring hundreds of lines of Transact-SQL code can be performed through a single statement that executes the code in a procedure, rather than by sending hundreds of lines of code over the network. Неспроста это... Таким образом, отвечая на вопрос "отличается ли производительность скомпилированных 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, дабы подтвердили/опровергли информацию о хранимках.

Автор: AleXGray 30.7.2008, 23:58

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

Автор: Idsa 31.7.2008, 00:01

Цитата(AleXGray @  31.7.2008,  03:58 ) Ну во всяком случае я сделал вывод о том, что все это чуть медленнее чем сырые запросы... Но зато насколько удобнее... Да и закон Мура нас лентяев уже который десяток лет выручает

Автор: AleXGray 31.7.2008, 23:07

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

Автор: mr.DUDA 4.8.2008, 11:24

Модератор: познавательную дискуссию о foreach вынес http://forum.vingrad.ru/index.php?showtopic=223121.

Автор: Fire44 22.9.2010, 23:42

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)