J’ai récemment parcouru un blog dont le sujet était “Comment mesurer le temps d’exécution de votre code”. En résumé, l’auteur de ce blog expliquait que lorsqu’on souhaite optimiser une webpart custom et autres composants SharePoint pour améliorer les performances, il peut être intéressant de mesurer le temps d’exécution de certains morceaux de code.

Il illustre son propos par ce bout de code :

   1:  var timer = System.Diagnostics.Stopwatch.StartNew();

   2:   

   3:  (your code goes here)

   4:   

   5:  timer.Stop();

   6:  Response.Write(timer.ElapsedMilliseconds);

Bien que correct et techniquement applicable à d’autres cas d’utilisation, ce post m’a paru étrange.

Il m’a fait réagir car il montre bien une des problématiques que nous rencontrons tout les jours en tant que Développeurs SharePoint lorsque nous devons proposer des solutions techniques. A savoir, le besoin de bien connaitre l’ensemble du framework .Net mais surtout de maitriser le framework SharePoint pour proposer la solution appropriée à nos client sans avoir à redévelopper un composant existant ou moins performant.

Dans le cas qui nous intéresse, je pense notamment à une autre façon de mesurer le temps d’exécution de nos composants : SPMonitoredScope

Son usage est très simple car il se base sur l’utilisation du Developper Dashboard :

Ce Developper Dashboard fournit diverses informations destinées au développeur :

• Thread execution time
• Number, duration, call stack information and query text of each SQL Server query generated by the page
• Number, duration, and call stack information of each WCF call
• URL or timer job name
• Current user
• Execution start time

Plus d’infos à ce sujet sur http://msdn.microsoft.com/en-us/library/ff512745.aspx

Vous pouvez l’activer de diverses manières : STSADM, Powershell ou par code.

   1:  Stsadm –o setproperty –pn developer-dashboard –pv ondemand (or “on” or “off”)

   2:   

   3:  $devDashboard = [Microsoft.SharePoint.Administration.SPWebService]::ContentService.DeveloperDashboardSettings;

   4:  $devDashboard.DisplayLevel = 'OnDemand';

   5:  $devDashboard.TraceEnabled = $true;

   6:  $devDashboard.Update() 

   7:   

   8:  SPWebService cs = SPWebService.ContentService;

   9:  cs.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.On;

  10:  cs.DeveloperDashboardSettings.Update();

  11:   

Pour revenir au sujet, en combinant SPMonitoredScope & le Developper Dashboard, il nous est possible de rajouter nos propres bouts de code dans le Developper Dashboard :

   1:  using (new SPMonitoredScope("OnLoad (GetSupplierInformationWP)"))

   2:  {

   3:   

   4:      using (new SPMonitoredScope("Construction de la requete CAML (GetSupplierInformationWP)"))

   5:      {

   6:          #region Construction de la requete CAML

   7:          …;

   8:          #endregion

   9:      }

  10:   

  11:      using (new SPMonitoredScope("Affichage des données (GetSupplierInformationWP)"))

  12:      {

  13:          #region Affichage des données

  14:          …;

  15:          #endregion

  16:      }

  17:   

  18:      using (new SPMonitoredScope("CleanUp & Dispose (GetSupplierInformationWP)"))

  19:      {

  20:          #region CleanUp & Dispose

  21:          …;

  22:          #endregion

  23:      }

  24:  }

Ce qui nous donne :

Ca peut s’avérer pratique pendant les phases de debug sur certains composants “poilus”.

<Philippe/>