Joel Greijer

Large biml solutions might be slow. These steps are good to take to be able to pinpoint slow spots. Create Debug.biml  Add debug.biml last to your project. As there is no way to get the name of the current file in BIML we use a hack that requires at least one other biml-file containing at least one connection tag to be generated.  < #@ template language = "C#" tier = "900" #> < #@ import namespace = "System.Diagnostics" #> < #@ import namespace = "System.Xml" #> < Biml xmlns = "http://schemas.varigence.com/biml.xsd" > < Annotations > < Annotation AnnotationType = "CodeComment" > < #=DateTime.Now.ToString("s")# > Debug start time </ Annotation > </ Annotations > < # string xBiml = RootNode.GetBiml(); XmlDocument xmlDoc = new XmlDocument (); xmlDoc.LoadXml ( xBiml ); if ( RootNode.Connect...

Tested on Sql Azure 11.0.9206.32 /* Get actual reads, writes and other nice to know stuff for benchmarking. Notice go statements which are crucial since stats seem to update by batch. */   go if   object_id ( 'tempdb..#stats' )   is   not   null   drop   table   #stats  select   getdate ( )   as   startTime , cpu_time , memory_usage , reads , writes , logical_reads , session_id   into   #stats   from   sys . dm_exec_sessions   a   where   session_id = @@spid go --do your magic stuff that need tuning go select      datediff ( ms , s2 . startTime , getdate ( ) )   as   ElapsedMs ,      s1 . cpu_time - s2 . cpu_time   as   cpu_time ,      s1 . memory_usage - s2 . memory_usage  ...