The First execution of a Stored Proc shows a delay between SP:StmtStarting and SP:Starting

Question

We experience a performanceproblem with some of our Stored Procedures. SQL Server is "Microsoft SQL Server 2012 (SP1) - 11.0.3128.0 (X64)"
Situation:
SQL Server Proc1 executes some SQL Statement and starts some other SQL Stored Procedures. I open a SQL Management Studio Session "example session_id 105", trace the session 105 with the SQL Server Profiler.
I start Proc 1, when Proc1 starts the execution of Proc 2, the Profiler Trace shows a delay of 6 seconds between SP:StmtStarting "execute db..proc2 @SomeVar" and SP:Starting "execute db..proc2 @SomeVar".
All following executions of Proc1 in the Session 105 runs without a delay between SP:StmtStarting "execute db..proc2 @SomeVar" and SP:Starting "execute db..proc2 @SomeVar".
But when i open a new SQL Server Management Session "session_id 124", the first execution of Proc1 when it executes Proc 1, there is again the delay of 6 seconds between SP:StmtStarting "execute db..proc2 @SomeVar" and SP:Starting "execute
db..proc2 @SomeVar".
Proc 1 starts the execution of Proc2 with a simple execute statement like this:
Execute DB..Proc2 @SomeVar
So its not dynamic SQL.
What is SQL Server doing? I understand that SQL Server has to do some work when it executes the first time a Stored Procedure. But why is the SQL Server doing it in every new Session?
How can i prevent this behavior or how to make it faster?
Best Regards
Paolo

Answer 1

>In my case the temp tables ruined the performance.
Creating temp tables takes time & resources. Temporary table usage should be justified and tested in stored procedures. There are cases when temporary table usage is helpful especially with very complex queries.
In your case it appears that not one but several temp tables were applied. That can be punishing.
Paul White's blog: "Ask anyone what the primary advantage of temporary tables over
table variables is, and the chances are they will say that temporary tables support statistics and table variables do not.  This is true, of course; even the indexes that enforce PRIMARY KEY and UNIQUE constraints on table variables do not have
populated statistics associated with them, and it is not possible to manually create statistics or non-constraint indexes on table variables.  Intuitively, then, any query that has alternative execution plans to choose from ought to benefit from using
a temporary table rather than a table variable.  This is also true, up to a point.
The most common use of temporary tables is in stored procedures, where they can be very useful as a way of simplifying a large query into smaller parts, giving the optimizer a better chance of finding good execution plans, providing statistical
information about an intermediate result set, and probably making future maintenance of the procedure easier as well.  In case it is not obvious, breaking a complex query into smaller steps using temporary tables makes life easier for the optimizer in
several ways.  Smaller queries tend to have a smaller number of possible execution plans, reducing the chances that the optimizer will miss a good one.  Complex queries are also less likely to have good cardinality (row count) estimates and statistical
information, since small errors tend to grow quickly as more and more operators appear in the plan.
This is a very important point that is not widely appreciated.  The SQL Server query optimizer is only as good as the information it has to work with.  If cardinality or statistical information is badly wrong
at any point in the plan, the result will most likely be a poor execution plan selection from that point forward.  It is not just a matter of creating and maintaining appropriate statistics on the base tables, either.  The optimizer does
use these as a starting point, but it also derives new statistics at every plan operator, and things can quickly conspire to make these (invisible) derived statistics hopelessly wrong.  The only real sign that something is wrong (aside from poor performance,
naturally) is that actual row counts vary widely from the optimizer’s estimate.  Sadly, SQL Server does not make it easy today to routinely collect and analyse differences between cardinality estimates and runtime row counts, though some small (but welcome)
steps forward have been made in SQL Server 2012 with new row count information in the
sys.dm_exec_query_stats view.
The benefits of using simplifying temporary tables where necessary are potentially better execution plans, now and in the future as data distribution changes and new execution plans are compiled.  On the cost side of the ledger we have
the extra effort needed to populate the temporary table, and maintain the statistics.  In addition, we expect a higher number of recompilations for optimality reasons due to changes in statistics.  In short, we have a trade-off between potential
execution plan quality and maintenance/recompilation cost.
LINK:
http://sqlblog.com/blogs/paul_white/archive/2012/08/15/temporary-tables-in-stored-procedures.aspx
Kalman Toth Database & OLAP Architect
IPAD SELECT Query Video Tutorial 3.5 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012