Fermer

septembre 10, 2020

Comparaison des performances: Telerik DataGrid, JavaScript, Blazor


Pouvez-vous obtenir une augmentation significative des performances en écrivant votre propre code Blazor ou JavaScript au lieu d'utiliser Telerik DataGrid? Probablement pas.

Lorsque vous créez votre interface utilisateur, vous avez trois options: l'écrire en JavaScript, l'écrire dans Blazor, utiliser un composant tiers. De toute évidence, le composant tiers (comme le DataGrid dans Telerik UI pour Blazor ) vous donnera plus de fonctionnalités avec moins d'effort… mais qu'en est-il des performances?

Mon attitude envers l'amélioration des performances, en particulier lorsque je parle de le code côté client peut sembler pervers: je ne suis pas vraiment intéressé par quelque chose de «plus rapide» à moins que mon utilisateur ne le remarque. À moins qu'une amélioration de la vitesse ne provoque un "Wow, c'était plus rapide!" de mon utilisateur, je m'en fiche.

Mais cela ne veut pas dire que les performances n’ont pas d’importance pour moi: si je peux obtenir ce "Wow!" expérience, je la veux (à condition de ne pas avoir à écrire une énorme quantité de code pour l’obtenir). Au cours de mes derniers quelques messages, j'ai examiné les fonctionnalités fournies par l'interface utilisateur Telerik pour Blazor DataGrid. Je pense qu'il est juste de voir ce que l'utilisation de cette grille pourrait me coûter en termes de performances.

Dans la discussion suivante, au fait, j'ai ignoré le temps de téléchargement de l'infrastructure Blazor: j'ai démarré l'horloge quelque temps après mon le code a commencé à s'exécuter. Dans ces tests, j'ai comparé Blazor à JavaScript et jQuery «purs». Si j'avais comparé Blazor à un autre framework (par exemple React, Angular ou Vue), j'aurais considéré le temps de téléchargement.

Mon scénario

Compte tenu du taux de refacturation d'un développeur ((taux horaire + avantages + coûts de gestion ) x temps passé au travail), personne ne tentera de créer un composant avec autant de fonctionnalités que DataGrid dans l'interface utilisateur Telerik pour Blazor – il est plus efficace d'obtenir un composant tiers. Cependant, vous pourriez envisager de construire quelque chose qui ne fasse «que cette seule chose».

Sur cette base, j'ai décidé que le scénario conduisant ma comparaison serait: «Et si j'avais besoin d'une page affichant simplement un tableau de données? Quelle technologie me donnera les performances qui me intéressent: du JavaScript pur, mon propre composant dynamique ou le Telerik DataGrid? » Il m'a semblé évident que le DataGrid allait perdre cette course: même réduit à ses bases, la grille va faire (et configurer pour faire plus) que le code que je pourrais écrire pour générer un tas de balises de table . Mais, quand même, je voulais savoir quel serait le coût.

Pour ce scénario, j'ai exécuté trois tests pour chacune des technologies: Temps d'affichage initial, temps de réaffichage de la page si j'utilisais le bouton d'actualisation du navigateur , et le temps de réafficher si j'utilisais un bouton pour recréer l'affichage sans avoir à récupérer les données. Dans tous les cas, j'ai ignoré l'heure de la première exécution et n'ai utilisé que les temps des exécutions suivantes.

Configuration

Vous pouvez probablement sauter ceci et aller directement à la section suivante où je donne mes résultats. Cela ne vous intéressera que si vous remettez en question ces résultats et que vous voulez contester comment je les ai obtenus.

Pour tester le Telerik DataGrid, j'ai ajouté un TelerikGrid barebones à ma page Razor. J'ai désactivé la pagination parce que je n'allais pas mettre en œuvre la pagination dans l'un ou l'autre de mes deux autres cas, mais je n'ai désactivé aucune autre option non plus. Voici le balisage résultant:

J'ai récupéré mes objets à partir d'un service Web et les ai chargés dans la collection à laquelle ma grille était liée dans la méthode OnInitializedAsync de mon composant. Voici ce code:

 async protected override Task  OnInitializedAsync  () 
 {
   HttpClient hc  =  nouveau  HttpClient  () ; 
   HttpResponseMessage hrm  =  attend
            hc .  GetAsync  ( "https: // localhost: 44380 / api / EmployeeService" ) ; 
   MyData  =  wait hrm .  Content .  ReadFromJsonAsync  < List  < Employee  >>  () ; 
   wait base .  OnInitializedAsync  () ; 
}

Cela a pris soin de mon test de grille.

Pour tester la génération d'une table sans grille, j'ai utilisé un RenderFragment appelé depuis ma page .razor pour créer ma table. Ce code a commencé et s'est terminé comme ceci (je ne vais pas tout inclure… c'est vraiment ennuyeux):

 RenderFragment  CreateTable  () 
 {
   Table RenderFragment ; 

   tableau  =  b  = > 
    {
      b .  OpenElement  ( 1   "table" ) ; 

      b .  OpenElement  ( 2   "thead" ) ; 
      b .  AddAttribute  ( 2   "class"   "k-grid-table" ) ; 
      … Code omis…
       foreach   ( Employee emp in MyData ) 
       {
         b .  OpenElement  ( 3   "tr" ) ; 
         b .  AddAttribute  ( 3   "class"   "k-master-row" ) ; 

         b .  OpenElement  ( 4   "td" ) ; 
         b .  AddContent  ( 4  emp .  Id ) ; 
         b .  CloseElement  () ; 
         … Code omis…
         b .  CloseElement  () ; 
      } 
      b .  CloseElement  () ; 
      b .  CloseElement  () ; 
   } ; 
    return  table ; 
}

Pour le test d'affichage initial, j'ai démarré mon minuteur juste avant de créer le HttpClient et capturé mon «heure de fin» dans l'événement AfterRender de la page. Pour tester la réaffichage des données avec la grille, j'ai défini la collection conduisant ma grille sur une liste vide, démarré mon horloge, puis redéfini la collection de la grille sur les données. Pour le test de «réaffichage des données», je viens de démarrer l'horloge en haut de la méthode qui a renvoyé le RenderFragment. J'ai fait tous mes tests en utilisant une version Release.

Pour générer la table en JavaScript, pour l'affichage initial, j'ai utilisé du code comme ce test pour extraire mes objets d'un service Web et les envelopper dans une table (encore une fois, j'ai gagné n'inclut pas tout le code fastidieux):

 function   GetDataAndBuildTable  ()   {
   $ .  getJSON  ( "https: // localhost: 44380 / api / EmployeeService"  buildTable ) ; 
} [19659129] function   buildTable  ( emps )   {
    let  empTable  =   $  ( " ")  buildHeader  ( empTable ) ;  let  empBody  =  $  ("  ") 
   emps .  forEach  ( function  ( emp )  { buildRow  ( emp  empBody ) 
            empTable .  append  ( empBody ) ; } ) ; 
    empTable .  append  ( empBody ) ;  $  ( "# empDiv" ) . [19659021] append  ( empTable ) ; } ) ; 
… Fonctions omises…
 function  buildCell  ( prp  emp  row )  { let  empCell  ] =  $  ( "" ) .  appendTo  ( row ) ; 
   row .  append  ( empCell ) ; } 
 Pour mon test d'affichage initial JavaScript, j'ai démarré mon horloge lorsque j'ai appelé le service Web . J'ai capturé mon «heure de fin» après avoir ajouté mon élément de table à la balise div sur la page. Pour réafficher sans relecture, j'ai simplement extrait mon code du tableau que j'avais déjà récupéré.
 Prendre mon heure de fin lorsque j'ai ajouté l'élément de table peut donner un avantage à mon test JavaScript en ignorant le temps de rendu … mais je ne le fais pas. t vraiment soin. De toute évidence, ces mesures sont au mieux grossières, mais je ne m'intéresse qu'aux différences flagrantes. Je me fiche de la différence entre deux tests à moins qu'il n'y ait  au moins  une différence d'un quart de seconde car je ne pense pas que les utilisateurs puissent détecter quoi que ce soit de plus petit.
 Les résultats
 Le code JavaScript a pris entre 25 et 30 millisecondes pour accéder à l'affichage initial, tout comme le rafraîchissement du navigateur. La reconstruction de la table sans récupérer les données prenait entre 9 et 30 millisecondes (c'est-à-dire parfois plus rapide que l'affichage initial).
 Le DataGrid a pris entre 250 et 280 millisecondes pour l'affichage initial. Cela s'est accéléré lorsque j'ai rafraîchi le navigateur: entre 210 et 230 millisecondes. L'actualisation de la grille sans relecture était plus rapide, entre 150 et 220 millisecondes. Par rapport à JavaScript, vous pourriez généraliser et dire que les choses prenaient jusqu'à 200 millisecondes de plus (ou aussi peu que 120 millisecondes de plus).
 La création de la table dans Blazor à l'aide d'un RenderFragment prenait entre 60 et 100 millisecondes pour l'affichage initial. Pas aussi rapide que le JavaScript (qui était 30 à 40 millisecondes plus rapide). L'actualisation du navigateur a pris à peu près le même temps. Réexécuter le code pour réafficher la page, par contre, était plus rapide que le JavaScript: entre 5 et 10 millisecondes.
 J'ai d'abord effectué tous ces tests dans Chrome, d'ailleurs. De toute évidence, passer à un autre navigateur donnerait des résultats différents, car j'utiliserais différents moteurs JavaScript et WebAssembly. Cela dit, j'ai répété les tests dans Internet Edge et je n'ai pas beaucoup changé. La seule différence significative était que le Telerik DataGrid a mis plus de temps pour atteindre l'affichage initial dans Edge d'environ 200 millisecondes, une différence approchant, mais toujours à l'intérieur, de ma limite «Je m'en fous».
 Bien que cela ne soit pas strictement pertinent, J'ai également mesuré le temps nécessaire pour passer mon appel Ajax et analyser le JSON résultant. En JavaScript, j'ai mesuré le temps écoulé entre l'appel de getJSON et le début de la fonction de rappel invoquée par l'appel getJSON: cela s'est passé entre 15 et 20 millisecondes. Pour Blazor, j'ai mesuré le temps entre la création de l'objet HttpClient et juste après le chargement de la liste contenant mes données: cela s'est avéré être compris entre 210 et 260 millisecondes. Encore une fois, juste avant ma note «Je m'en fiche».
 Conclusions
 J'en suis venu à deux conclusions et demie.
  Première conclusion:  J'essaie désespérément de m'en soucier . La plus grande différence que j'ai pu obtenir était un cinquième de seconde. Les différences étaient si petites que, effectivement, toutes les technologies aboutissaient à un affichage instantané (ignorant, comme je l'ai dit au début, le temps de télécharger l'infrastructure Blazor). Compte tenu du temps nécessaire pour passer un appel de service Web dans Blazor, vous devez structurer votre application pour ne faire qu'un seul gros appel à la fois, plutôt que de faire une série d'appels plus petits (mais c'est juste une bonne gestion des données: faites aussi peu de déplacements votre serveur de données que possible à tout moment).
  Deuxièmement:  Si vous voulez vous soucier des performances et avez l'intention de tout construire vous-même… eh bien, sur la base de ces tests (et en supposant que les performances sont tout qui compte pour vous), alors vous devriez le faire dans Blazor. Ce que j’ai trouvé plutôt sympa à découvrir.
 Mais si nous voulons parler de performance, nous devons aussi parler d’efficacité. L'affichage de la table à l'aide du Telerik DataGrid a pris environ 4 lignes de code; la version JavaScript a pris environ 40 lignes; la version Blazor, environ 50 lignes. Mon temps est mieux passé à exploiter le DataGrid même si je fais la tâche la plus simple possible: simplement afficher un tableau. Et, bien sûr, vous n'allez jamais «simplement afficher un tableau».
 Le meilleur outil 2023 pour ta croissance Instagram ! 
 



Source link 
     

   

      
   
   
    
  
    
"   +  emp  [ prp ]   +   "