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/>