Esta pergunta é inspirada no comentário postado na última postagem do blog ServerFault :
Vocês ainda estão usando LINQ to SQL?
Sei que posso usar o SQL Server Profiler e/ou o ToTraceStringmétodo para ver as consultas geradas e analisá-las eu mesmo. No entanto, estou procurando opiniões de pessoas com experiência prática na administração de bancos de dados acessados por aplicativos que utilizam o Entity Framework .
As consultas do Entity Framework são uma causa comum de problemas de desempenho?
As consultas LINQ podem ser otimizadas nesses casos ou o Transact-SQL bruto é a única solução?
Depende de quais são as consultas. Os ORMs geralmente são muito bons em CRUD, pois geralmente são simples. Quanto mais complexa a consulta, maior a chance de uma consulta inválida. Você pode ajustar as consultas geradas ajustando as instruções LINQ. Mais cedo ou mais tarde, porém, você se cansará de lutar e usar consultas SQL ou procedimentos armazenados para qualquer coisa que seja complexa.
Consultas individuais estão ok
Um dos maiores 'problemas' de desempenho com ferramentas ORM (Entity Framework, Linq, LLBLGen , NHibernate , etc... ) não é tanto o desempenho das consultas individuais que são executadas (a maioria são apenas chamadas CRUD que estão recuperando um único gravar de volta com base em uma chave primária).
Uso incorreto de carregamento preguiçoso = desempenho ruim
É o uso incorreto do carregamento lento, onde se você não configurou seus atributos de pré-busca corretamente, pode acabar com um número significativo de execuções no banco de dados (algo que poderia ter sido recuperado em uma única chamada ao banco de dados, torna-se 200 executa, com toda a sobrecarga de rede e IO associada a eles)
de LINQ para SQL, Lazy Loading e Prefetching
A chave é saber o que você está acessando
A verdadeira diferença entre usar um ORM e manipulá-lo você mesmo é que, quando você mesmo o codifica, é forçado a pensar em como o SQL deve ser estruturado e pode facilmente entrar e ajustá-lo para o cenário específico que está tentando resolver.
Considerando que, ao usar um ORM, você fica limitado pelas opções e personalização que a ferramenta ORM oferece, e muitos desenvolvedores apenas deixam isso para a própria ferramenta ORM (presumindo/esperando que ela apresente o melhor plano), e é por isso que ORM ferramentas são amplamente consideradas boas para CRUD, mas não para operações mais complexas...
Nota: Lazy loading pode ser uma coisa muito boa , é quando é usado de forma inadequada que é esse o problema...
Linq to SQL e Linq to Entities (Entity Framework) são algumas implementações diferentes. O primeiro é ORM mais antigo e mais leve do que o segundo. Alguém gosta de usar o primeiro por causa do desempenho. Aqui estão alguns links para descobrir as diferenças entre essas tecnologias:
Entity Framework vs LINQ to SQL LINQ to SQL vs ADO.NET Entity Framework
Este artigo explica por que o EF é tão lento e como aumentar o desempenho (se possível :)):
Ajuste de Consulta EF
O principal problema: a primeira chamada ao banco de dados (criação de entidades, mapeamento...) é muito lenta. Portanto, ainda prefiro procedimentos armazenados antigos e bons para consultas críticas (aplicativos). Como variante é possível usar EF (é minha opinião) com cache de aplicativo com pré-carregamento.