Потихоньку начинаю ковырять 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 в вопросе я думаю. 


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