SQL Server 2012 & sp_describe_first_result_set performance overhead?

Question

Hi All,
I'm just wondering if anyone has had the same experience as me when testing queries between SQL Server 2008 R2 SP2 (our DEV Server) and SQL Server 2012 SP1 (our soon to be PROD server).
We have a query the Spatial Services department run on their DEV server which executes (at an average) of 300ms.
On the (to be) PROD server (the 2012 SP1 box) the same query also runs at an average of 300ms. The query plans and the clients stats are almost identical. Happy with that. All good.
The problem that we are seeing is that the PROD server (2012) runs this darned
sp_describe_first_result_set procedure prior to executing the actual query itself and the execution of sp_describe_first_result_set takes (on average) 3200ms (returning 27 rows). This is a consistent number. So on
our DEV server the testing of the app takes around 300ms and returns results almost instantly yet testing the same app and same query on SQL 2012 takes around 3.5 seconds.
Seriously?
This obviously is not acceptable, especially in an environment that requires highly performant code.
My questions are:
Is this normal?
Has anyone else experienced this overhead?
Can it be avoided/turned off?
Any information would be greatly appreciated :)
Regards,
Glenn

Answer 1

Hi Erland,
Thanks for coming back to me with something to try out.
When you say "takes a long time to get through" I am guessing that you mean a long time for the engine to look at the query, interrogate it and send back the "metadata" about that particular query? 
Unfortunately these queries are generated by the client application which construct and throw dynamic SQL at SQL Server for execution.
On digging further the query generated actually pulls data from a view. This view is constructed to pull data together from 2 remote Servers (1 SQL Server and 1 Sybase server). Executing the view (i.e. selecting the actual query that makes up the view and pressing
F5) returns data from these two servers almost instantaneously on both the DEV and PROD servers because the view being called on both DEV and PROD servers are actually pointing to the same remote servers (so the data is exactly the same).
As object metadata information is stored locally to each user database I would assume (and of course I may be wrong) that this information would be obtained from the underlying syscolumns view and therefore should be rather quick (i.e. instantaneous?)
I'm have no idea about the underlying mechanics of how this new SP sp_describe_first_result_set works so am not sure. It is instantaneous when querying information about local tables (and views that use local tables) but as soon as it queries
views that rely on remote table data the performance goes out the window. Surely its not using (trying to get) remote metadata information?????
Thanks for your time.
Glenn
SQL Server, its a gas!