none
Performance SqlDataAdapter RRS feed

  • Question

  • Bonjour,

    Je voulais savoir si il avait la possibilité de rendre plus performant un SqlDataAdapter ?

    J'ai remarqué que la méthode suivante pouvait prendre pas mal de ressources.

    adapter.Fill(dataSet);

    (Remarque : C'est à nuancer car au lancement de l'applicatif sur lequel je travaille, un ensemble de tables de référence sont sélectionnées dans une procédure T-SQL)

    En dehors de considération sur la partie SQL, est-ce qu'il y a un moyen d'optimiser un SqlDataAdapter ?

    Merci


    • Modifié GRANET jeudi 12 mars 2015 15:10
    jeudi 12 mars 2015 15:10

Réponses

  • Bonjour,

    Normalement ce n'est pas votre adapter qui consomme des ressources, il n'est qu'un "conteneur" d'instructions SQL grâce auxquelles il va remplir votre Dataset. C'est plus votre dataset qui va consommer des ressources car c'est lui qui maintient toutes les lignes de votre requête en mémoire.

    Si vous avez des problèmes avec cela je serais plus enclin à penser que vous récupérez beaucoup de lignes de données. Et c'est la pertinence de garder toutes ces lignes en mémoire qui est à étudier.

    Donc déterminez les lignes que vous devez absolument garder en mémoire, déterminez si vous ne récupérez pas des colonnes inutiles (elles seront téléchargées et gardées en mémoire pour rien). Sauf en cas de nécessité utilisez des clauses TOP pour limiter le nombre de lignes (inutiles de télécharger les 10000 lignes d'un historique client si les utilisateurs ne se servent que des 20 premières).

    Cordialement,


    Yan Grenier

    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont répondues à votre question, et de noter les réponses que vous avez trouvé utiles.

    • Proposé comme réponse PhGr_ vendredi 13 mars 2015 08:33
    • Marqué comme réponse GRANET mardi 17 mars 2015 14:11
    vendredi 13 mars 2015 08:08
  • Il n'y a rien de curieux, le mécanisme de Adapter/Dataset n'est pas le plus performant en terme de ressources. Ils existent plus pour faciliter le travail du développeur que pour être performants.

    D'ailleurs il ne sont plus vraiment préconisés comme outils de gestion des données, aujourd'hui on privilégie soit le bas niveau avec des datareaders (mais il faut tout gérer - typage, stockage), soit des ORM comme Entity Framework, mais là également on peut rencontrer des problèmes de ressources éventuelles.

    Les méthodes les plus sûrs restent la maîtrise du volume de données renvoyées.

    Cordialement,


    Yan Grenier

    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont répondues à votre question, et de noter les réponses que vous avez trouvé utiles.

    • Marqué comme réponse GRANET mardi 17 mars 2015 14:07
    mardi 17 mars 2015 12:41

Toutes les réponses

  • Bonjour,

    Normalement ce n'est pas votre adapter qui consomme des ressources, il n'est qu'un "conteneur" d'instructions SQL grâce auxquelles il va remplir votre Dataset. C'est plus votre dataset qui va consommer des ressources car c'est lui qui maintient toutes les lignes de votre requête en mémoire.

    Si vous avez des problèmes avec cela je serais plus enclin à penser que vous récupérez beaucoup de lignes de données. Et c'est la pertinence de garder toutes ces lignes en mémoire qui est à étudier.

    Donc déterminez les lignes que vous devez absolument garder en mémoire, déterminez si vous ne récupérez pas des colonnes inutiles (elles seront téléchargées et gardées en mémoire pour rien). Sauf en cas de nécessité utilisez des clauses TOP pour limiter le nombre de lignes (inutiles de télécharger les 10000 lignes d'un historique client si les utilisateurs ne se servent que des 20 premières).

    Cordialement,


    Yan Grenier

    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont répondues à votre question, et de noter les réponses que vous avez trouvé utiles.

    • Proposé comme réponse PhGr_ vendredi 13 mars 2015 08:33
    • Marqué comme réponse GRANET mardi 17 mars 2015 14:11
    vendredi 13 mars 2015 08:08
  • Oui effectivement c'est curieux, c'est en lançant l'analyse de performance sous VS2010 que je me suis rendu compte de cette consommation de ressource au niveau de adapter.Fill(dataSet) que je n'arrive pas à expliquer.

    Par contre vous avez raison, lors de la récupération des données, toutes les colonnes sont récupérées systématiquement,  ainsi que la quantité de données remontées sont des points à étudier.

    Cette consommation par l'adapter reste néanmoins curieuse.

    mardi 17 mars 2015 08:30
  • Il n'y a rien de curieux, le mécanisme de Adapter/Dataset n'est pas le plus performant en terme de ressources. Ils existent plus pour faciliter le travail du développeur que pour être performants.

    D'ailleurs il ne sont plus vraiment préconisés comme outils de gestion des données, aujourd'hui on privilégie soit le bas niveau avec des datareaders (mais il faut tout gérer - typage, stockage), soit des ORM comme Entity Framework, mais là également on peut rencontrer des problèmes de ressources éventuelles.

    Les méthodes les plus sûrs restent la maîtrise du volume de données renvoyées.

    Cordialement,


    Yan Grenier

    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont répondues à votre question, et de noter les réponses que vous avez trouvé utiles.

    • Marqué comme réponse GRANET mardi 17 mars 2015 14:07
    mardi 17 mars 2015 12:41
  • Merci pour cet éclaircissement, donc si j'ai bien compris au délà de la maîtrise du volume de données, le mécanisme Adapter/Dataset n'est clairement plus d'actualité en terme de performance ?

    L'écart de performance par rapport à "Entity Framework" est important ?



    • Modifié GRANET mardi 17 mars 2015 14:10
    mardi 17 mars 2015 14:09
  • Non il existe pour la compatibilité ascendante d'ailleurs la team ADO.Net ne travaille plus dessus depuis quelques années.

    L'écart de performance, je ne pourrais pas le dire honnêtement, tant que je ne rencontre pas de problème particulier je ne pose pas la question.

    La plupart de temps je règle mes problèmes en optimisant mes requêtes, en créant des vues ou des procédures stockées sur le serveur, etc.. Bref le goulot d'étranglement pour moi reste mes requêtes. Si pour obtenir mes données ca me prends plus de ressource soit j'ai mal fait mon boulot, soit je n'ai pas le choix alors ca devient un "prérequis" à l'application.

    Maintenant je fais essentiellement des applications de gestion, donc avec 500Mo de RAM (j'exagère un peu ;) ) pour traiter des statistiques de production ne pose pas de problème à mes clients.

    Si j'ai besoin de perf maximum (ça m'est arrivé une fois) j'ai utilisé des algo avec des datareaders donc le "bas niveau" de ADO.Net.

    Cordialement,


    Yan Grenier

    Merci de bien vouloir "Marquer comme réponse", les réponses qui ont répondues à votre question, et de noter les réponses que vous avez trouvé utiles.

    mardi 17 mars 2015 17:28