Primeiro, verifique se você está criando o perfil do desempenho corretamente. Por exemplo, execute a consulta duas vezes no ADO.NET e veja se a segunda vez é muito mais rápida que a primeira. Isso remove a sobrecarga de aguardar a compilação do aplicativo e a aceleração da infraestrutura de depuração.
Em seguida, verifique as configurações padrão em ADO.NET e SSMS. Por exemplo, se você executar SET ARITHABORT OFF no SSMS, poderá descobrir que agora ele é executado tão lentamente quanto ao usar o ADO.NET.
O que eu encontrei uma vez foi que SET ARITHABORT OFF no SSMS fez com que o proc armazenado fosse recompilado e/ou estatísticas diferentes fossem usadas. E, de repente, tanto o SSMS quanto o ADO.NET estavam relatando aproximadamente o mesmo tempo de execução.
Para verificar isso, observe os planos de execução para cada execução, especificamente a tabela syscacheobjects. Provavelmente serão diferentes.
A execução de 'sp_recompile' em um procedimento armazenado específico descartará o plano de execução associado do cache, o que dará ao SQL Server a chance de criar um plano possivelmente mais apropriado na próxima execução do procedimento.
Finalmente, você pode tentar a abordagem "nuke it from orbit" de limpar todo o cache do procedimento e os buffers de memória usando o SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Fazer isso antes de testar sua consulta impede o uso de planos de execução em cache e cache de resultados anteriores.
