Datagridview Virtual Mode
Bonjour à tous,
j'ai un grand volume de données (530000 lignes, 14 champs,non modifiable) à afficher dans un Datagridview (DGV), dans le but de comparer les perfomances entre un affichage en c# .net avec ce Datagridview et un composant Table Box de l'ERP Microsoft Dynamics Navision, les deux pointant donc vers la même table comportant ces 530000 records, la base de données est SQL Server 2008.
d'après le MSDN, pour l'affichage d'un grand nombre d'enregistrement, il préconise de passser le DGV en Virtual mode à true, et utiliser l'évènement CellValueNeeded etc...
je pensais que ça aller permettre d'optimiser le temps de chargement initial du DGV et la mémoire occupé par le jeux de données renvoyés.
j'ai certainement du me tromper, mais je ne constate pas d'amélioration, par rapport à l'utilisation de la propriété Datasource et du Binding (Fill), car même en virtual Mode il faut remplir un objet contenant les données à afficher.
les résulats que je constate :
- Datasource + méthode Fill : 30 secondes pour ouvrir le Winfrom contenant le DGV avec les 530000 lignes et plus de 600 Mo d'occupation mémoire, scroll des données dans le DGV sans temps de latence
- Virtual Mode + CellValueNeeded : 10 seconde pour ouvrir le Winfrom contenant le DGV avec les 530000 lignes et plus de 200 Mo d'occupation mémoire, scroll des données dans le DGV sans temps de latence
- SQLDataReader + CellValueNeeded : ouverture du Winform instanée et 8 Mo d'occupation mémoire, le problème c'est que le SQLDataReader ne permet que d'avancé (forward) dans le jeux de données envoyé , scroll des données dans le DGV sans temps de latence mais que dans un sens.
- pour finir l'ERP Navision avec son langague propriétaire qui date de 1995 (je crois) ouvre instanément le formulaire contenant le Table Box avec les 530000 lignes et entre 6 et 8 Mo d'occupation mémoire, scroll des données sans temps de latence, et insertion, modification et suppression en temps réels !
à croire que le proverbe se vérifie : "c'est dans les vieilles marmites qu'on fait les meilleurs soupes". ;)
j'ai essayé de trouver un subterfuge avec la méthode FILL qui peut prendre en paramètre index de l'enregistrement de départ et le nombre d'engistrement total pour essayé d'optimisé la mémoire et le temps, mais j'ai un temps de latence quand je demande le chargement dans le DGV de la prochaine borne d'enregistrement quand je scroll.
donc pour finir, à votre avis est-il possible en c# .net de refaire un composant au performance équivalente de celui de cet ERP ? si oui si vous avez une piste pour orienter mes recherches.
merci d'avance.
cordialement
