Se först till att du profilerar prestandan korrekt. Kör till exempel frågan två gånger från ADO.NET och se om andra gången är mycket snabbare än första gången. Detta tar bort omkostnaderna för att vänta på att appen ska kompileras och att felsökningsinfrastrukturen ska öka.
Kontrollera sedan standardinställningarna i ADO.NET och SSMS. Till exempel, om du kör SET ARITHABORT OFF i SSMS, kan du upptäcka att det nu går lika långsamt som när du använder ADO.NET.
Vad jag hittade en gång var att SET ARITHABORT AV i SSMS gjorde att den lagrade procen kompilerades om och/eller användes annan statistik. Och plötsligt rapporterade både SSMS och ADO.NET ungefär samma körtid.
För att kontrollera detta, titta på exekveringsplanerna för varje körning, särskilt tabellen syscacheobjects. De kommer förmodligen att vara annorlunda.
Att köra 'sp_recompile' på en specifik lagrad procedur kommer att ta bort den associerade exekveringsplanen från cachen, vilket sedan ger SQL Server en chans att skapa en möjligen mer lämplig plan vid nästa exekvering av proceduren.
Slutligen kan du prova "nuke it from orbit"-metoden att rensa ut hela procedurens cache och minnesbuffertar med SSMS:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
Om du gör det innan du testar din fråga förhindrar du användning av cachade körningsplaner och tidigare resultatcache.