When using compiled queries in entity framework (or linq-to-sql) in combination with SQL Server, is there actually still any performance benefit in using stored procedures?
Compiled queries will be cached as parameterized queries, so performance should be near equal to stored procedures. Is there any situation where stored procedures would perform significantly better?
-- EDIT --
In response to Yakimych's answer below, I didn't mean to imply that compiled queries are the same as stored procedures. I am trying to figure out if sprocs are still necessary if you have done all possible optimizations on the application side (in this case compiled queries). So I guess I'm looking for reasons why a stored procedure would be better than the combination of application-side optimizations and parameterized queries (which is what compiled queries effectively are).
One of the reasons I'm asking this, is because there are many people who seem to think that stored proedures are no longer necessary for different reasons (i.e. this post).
"Is there any situation where stored procedures would perform significantly better?"
Given a comparable piece of parametrized SQL generated in either EF or a stored proc, they will perform equally.
However, a DBA always has the opportunity to further optimise a query based on their experience with the DB schema and its usage patterns. A stored procedure allows them to do this easily in isolation of the applications using it, whereas an ORM doesn't.
We have an extremely complicated SQL Server DB that has many external systems replicating data in and out via triggers. The issue for us with EF is that the responsibility for the SQL that gets fired at the DB will become the application developers responsibility when using any ORM rather than the DBAs.