padrao do EF e que o contexto trabalhe com lazy loading. O que isso significa?Para quem esta seguindo o script, crie um projeto C# Console no Visual Studio e... 1. Adicione um ADO.NET Entity Data Model (chame do que quiser) 2. Escolha EF Designer from database 3. Aponte para seu banco de dados EF (pode manter o nome EFEntities) 4. Selecione as tabelas Pessoa, Endereco e Telefone 5. Clique em Finish Depois da geracao do modelo voce vai ver algo similar a imagem abaixo:Edite seu metodo Main e coloque o codigo abaixo. O objetivo do codigo e buscar quase 10000 pessoas e depois fazer algo simples, acessando o endereco e telefone do individuo (note que nao me interessa gerar saida alguma, so o acesso ao banco de dados).String s = "";DateTime dt = DateTime.Now;EFEntities contexto = new EFEntities();var r = contexto.Pessoas.Where(x => x.Codigo < 10000);foreach (var p in r.ToList()){ s = "Nome: " + p.Nome + " - Endereco: " + p.Endereco.Descricao + " - Telefone: " + p.Telefone.Descricao;}Console.WriteLine(DateTime.Now.Subtract(dt).Seconds.ToString());A execucao dessa aplicacao na minha maquina levou algo em torno de 12 segundos, nada demais para o desenvolvedor que esta executando este codigo, entao poucos fazem uma analise mais detalhada, como faremos a seguir.Utilizando o profiler para monitorar os eventos SQL:BatchCompleted e RPC:Completed, toda vez que o Entity Framework acessa a coluna Descricao da entidade Endereco ou Telefone, uma chamada e feita para o SQL Server (note o @EntityKeyValue1 variando), o que neste exemplo gerou 39998 entradas no profiler.Essas chamadas sao feitas porque o EF vai "preguicosamente" (lazy) pedindo para o SQL Server os elementos de outras entidades, varrendo o resultado retornado apos o acesso ao elemento Pessoa (primeira consulta exibida na imagem abaixo).Eager loadingCaso voce queira que o Entity Framework nao trabalhe com esse comportamento de lazy loading, voce pode alterar no seu codigo a utilizacao do contexto, adicionando o metodo "Include", que por debaixo dos planos ja busca todos os elementos.var r = contexto.Pessoas.Include("Endereco").Include("Telefone").Where(x => x.Codigo < 10000);Analisando a execucao deste novo codigo, temos APENAS DUAS linhas na saida do profiler, onde notamos que o EF enviou para o SQL Server uma unica consulta fazendo o join entre as tres tabelas, ja retornando o endereco e telefone. Dessa forma evitamos N round-trips entre o cliente e o servidor, fazendo com que em minha maquina o tempo total de execucao ficasse em torno de 3 segundos.Desempenho da aplicacaoA diferenca entre 3 e 12 segundos e onde mora o perigo... Talvez testando a solucao em sua maquina, os 9 segundos nao sejam significativos para os desenvolvedores, e um build sem a analise de desempenho ou do numero de chamadas acabe chegando em producao.Se a solucao e para controlar o nome dos envolvidos no proximo bolao do campeonato la na sua empresa, tudo tranquilo, porem caso a solucao tenha milhares de requisicoes pesquisando por pessoas especificas, o numero de chamadas ao banco de dados sera muito grande. E dependendo da forma como a aplicacao esta gerenciando e utilizando os seus recursos (ou consumindo os registros), ela mesmo pode ser tornar o gargalo, que nao