[R] Conseils pour accélérer affichage ListView

[aulus]

Bonjour,

Ma ListView affiche le contenu entier d'un fichier texte. Ce fichier texte peut compter plusieurs milliers de lignes.
J'ai fait un test avec un fichier de 4000 lignes. Il faut compter 7 à 10 secondes d'affichage pendant lesquelles la ListView s'agite comme un ver de terre, les lignes se bousculant les unes les autres. Tout ce temps sera à mon sens déstabillisant pour un futur utilisateur. J'ai cru, au cours des premiers tests, que mon programme était entré dans une boucle sans fin ou avait planté.

Existe-t-il un moyen d'empêcher ce phénomène ? Avez-vous une idée d'amélioration ?

Je vous remercie.

[tatane]

Bonsoir,

Avez-vous essayé en plaçant _GUICtrlListView_BeginUpdate() avant votre boucle de traitement et _GUICtrlListView_EndUpdate() après celle-ci ?
Cela devrait éviter le rafraichissement de la listview pendant le traitement.

[aulus]

Bonsoir et merci beaucoup.

Ces 2 fonctions ont en effet calmé l'affichage. Son temps me paraît même plus court.

Maintenant, si je tente de réorganiser l'ordre d'affichage en cliquant sur une tête de colonne de ma listView, le temps de réorganisation est toujours très long. L'avertissement "ne répond pas" s'affiche même dans la barre de titre du programme tant que la réorganisation n'est pas arrivée à son terme. A ce moment-là, l'avertissement disparaît.
Peut-on éviter cet avertissement qui n'a pas lieu d'être puisque le programme suit son petit bonhomme de chemin ? Là aussi peut-on activer l'opération ?

[tatane]

Là je ne sais pas trop. Il semblerait que le nombre important d'items de la listview rend son tri particulièrement long et donne l'impression à Windows 7 (je suppose) que le programme est planté.
Peut être faudrait il prendre le problème autrement. Par exemple, désactiver le tri de la colonne et créer un bouton TRI qui s'occuperait du traitement. Pendant le traitement une GUI popup avec une progressbar pourrait faire patienter l'utilisateur et vous pourriez désactiver (@Disable) la GUI principale tant que le traitement n'est pas terminé.
Vous devriez pouvoir trouver pas mal de code de tri sur la toile et probablement sur ce forum.

[aulus]

Je vous remercie pour vos conseils. Je vais tester ces propositions.

[aulus]

Bonjour,

Après tests, il s'avère que l'idée des boutons est bonne. J'ai un souci pour tous les caser dans ma fenêtre : souci de place et de présentation pas trop indigeste.

Merci encore.

[tatane]

Je vous en prie.

Pensez à changer le sujet en résolu : [R]

[aulus]

Je ne l'ai pas mis en résolu du fait que le problème de vitesse d'affichage n'a pas trouvé de solution lorsque l'on clique sur l'en-tête des colonnes d'une ListView, ce qui était l'objet de ma question.

[GaRydelaMer]

Bonjour

quelle est la vitesse pour le 1ér remplissage ? Après le click sur la colonne ou le bouton, est ce la fonction de tri ou la méthode pour réécrire les données dans la ListView qui est lente ?

[aulus]

Bonjour et merci.

J'ai calculé :

Il faut 8 secondes au 1° remplissage pour afficher 5000 lignes.
Il faut 25 secondes pour réorganiser une listView affichant ces mêmes 5000 lignes, après avoir cliqué sur une en-tête de colonne. Je n'échappe pas à l'avertissement "ne répond pas".

A mon sens, c'est la méthode de tri qui est lente.

[mikell]

Exact, c'est pourquoi le bdd-expert local conseillerait probablement d'utiliser une bdd plutôt qu'un fichier texte et de faire le tri avec 'ORDER BY' avant affichage

[aulus]

J'ai trouvé SQLite, module de base de données inclus dans AutoIt. Est-ce bien ça ?

[mikell]

C'est ça... l'idée serait au moment du tri de vider la listview, faire le tri dans la bdd, et réafficher dans la listview
Ya des chances que ça soit plus rapide qu'un tri direct de listview ou d'array

[aulus]

Maintenant, il me reste à étudier SQLite... Je n'ai pas fini de poser des questions !

Merci pour vos conseils.

[mikell]

Ce serait possible de le poster ce fichier géant ? c'est mieux si on peut faire des tests directement dessus

[aulus]

Bonjour Mikell,

Je ne peux publier sur le forum ce fichier qui appartient à mon association de généalogie. Par contre, si vous l'acceptez, je peux vous l'envoyer en fichier joint à un courriel pour que vous fassiez les tests.

[mikell]

ça roule
Sur le 1er test avec la bdd de 5200 lignes le tri est pratiquement instantané, le plus long c'est la mise à jour de la listview qui met entre 3 et 4 secondes sur mon XP
Check your mail

[jchd]

Je découvre ce fil un peu tard...

Au passage je rappelle qu'une petite extension SQLite de mon cru est disponible pour assurer une collation Unicode désaccentuée multi-linguale, par exemple, ainsi que de nombreuses autres fonctions, dont une recherche floue (toujours Unicode désaccentuée et multi-linguale). Ca peut être drôlement utile pour trier des noms/prénoms d'origines très diverses quand on ignore la graphie exacte.

La doc est en tête du source C.

Pour charger une extension SQLite voir ce post US.

Ceci dit, SQLite est de toute façon la plus efficace façon d'organiser le stockage de données généalogiques, comme d'ailleurs l'écrasante majorité des données applicatives dès lors que leur volume n'est plus insignifiant.

[aulus]

Grand merci à tous deux. Je sens que SQLite va occuper mes longues soirées d'été...
@Mikell : je vous ai envoyé une réponse par courriel.

[aulus]

@Mikell
J'ai mis en commentaire la ligne indiquée mais l'erreur subsiste.