Discussion :

[soa]

Bonjour

Je voulais vous demander s'il était normal qu'une ListView (affichage de type: detail), consomme un max de puissance CPU (à savoir 5-15% de taux d'utilisation CPU [Core Duo T2400]), juste parce qu'on la rafraichi toutes les 2,5 secondes.

Je précise que c'est bien l'affichage qui consomme la puissance et pas le traitement qu'il y a avant des donnés qu'on cherche à afficher.
De plus cette liste ne contient que 4-6 éléments, 5 colonnes et 2-3 groupes au max. Rien de plus!

J'en reviens toujours pas, rafraichir la listview toute les 2,5sec ne me semble pas exagéré.

Donc bref, question, est-ce que c'est normal?


Merci

[wizad]

En soi ça ne me semble pas plus anormal que ça. Quel technologie est-ce (WindowsForms, WPF, Silverlight,...)?

Par contre une remarque : pourquoi diable as-tu besoin de faire un "rafraîchissement" toute les 2,5s?

EDIT : peux tu nous montrer le code rafraîchissant cette listview?

[tomlev]

A mon avis c'est pas la ListView proprement dite qui consomme les ressources, mais plutôt le code qui charge les données... Elles viennent d'où ces données ? D'une base de données ?

[soa]

A mon avis c'est pas la ListView proprement dite qui consomme les ressources, mais plutôt le code qui charge les données... Elles viennent d'où ces données ? D'une base de données ?

Non non, comme je l'ai dit c'est pas le code qui sert à charger les donnés à afficher qui est en cause.
C'est simple à tester. Si je met uniquement en commentaire la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

maListview.add(monItem)

ben la charge CPU est pratiquement nulle, alors que l'objet monItem contient bien les donnés à afficher, respectivement le traitement pour récupérer les divers donné a bien été réalisé.
En plus ces donnés sont issues d'un objet, et non d'une db ou fichier, et sont de type String ou IPAddress, bref des trucs où on a pas besoin de faire beaucoup de conversion pour mettre dans un item de listview.

Encore plus bizarre, j'ai remarqué ce matin que même si je ne rafraichissais pas la listview toutes les 2.5sec, que je l'affichais seulement une fois et pas plus, ben la charge conso reste élevée (10-20%). C'est à plus rien y comprendre.

En résumé, dès qu'il y a un item à afficher cette satanée listview me pompe un max.

[soa]

En soi ça ne me semble pas plus anormal que ça. Quel technologie est-ce (WindowsForms, WPF, Silverlight,...)?

Par contre une remarque : pourquoi diable as-tu besoin de faire un "rafraîchissement" toute les 2,5s?

EDIT : peux tu nous montrer le code rafraîchissant cette listview?

C'est une liste des PC dispo sur le réseau local, et je check s'ils sont online ou pas, certes 2,5s c'est beaucoup, mais ca change rien, même sans timer, dés que la listview affiche les item ca pompe, même sans la rafréchir :S.


D'ailleurs je viens de tester une chose. Au lieu d'ajouter l'item (rempli) dans la liste view, j'affiche le contenu de l'item dans la console. Ben pas de problème conso minimal. Donc c'est bien la listview (OnPaint foireux???) qui est en cause :-/

EDIT:
Concrètement.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
                    Console.ForegroundColor = ConsoleColor.White;
                    Console.Write("{0}", lvItem.SubItems[1].Text);
 
                    Console.ForegroundColor = ConsoleColor.Green;
                    Console.Write("  {0}", lvItem.SubItems[2].Text);
                    Console.Write("  {0}", lvItem.SubItems[3].Text);
 
                    Console.ForegroundColor = ConsoleColor.Blue;
                    Console.Write("  {0}", lvItem.SubItems[4].Text);
 
                    Console.ForegroundColor = ConsoleColor.Red;
                    Console.WriteLine("  {0}", lvItem.SubItems[5].Text);
                    Console.ResetColor();
 
                    //lvHosts.Items.Add(lvItem);

La pas de prob. Par contre si je décommente la dernière ligne c'est la "cata".

(Le Subitems[0], c'est juste une icone 16x16px.)

[_PascalC_]

Salut, as-tu essayé d'interrompre la logique de redessin du ListView pendant que tu rechargeais les données ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
listview1.BeginUpdate();
for(int i=0; i < 100; i++)
    listview1.Items.Add("...");
listview1.EndUpdate();

Pascal

[soa]

Salut, as-tu essayé d'interrompre la logique de redessin du ListView pendant que tu rechargeais les données ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
listview1.BeginUpdate();
for(int i=0; i < 100; i++)
    listview1.Items.Add("...");
listview1.EndUpdate();

Pascal

Salut

Oui j'avais déjà testé ca aussi. Ca ne change rien.


C'est désespérant ce truc :/. C'est une appli qui doit tourner en fond de tâche, mais si elle pompe 20% de CPU pour rien, c'est nulle. Bon alors certes dès que je ferme la fenêtre contenant la listview la charge CPU revient à la normal, mais quand même. :-/

Mince c'est juste une fenêtre avec 2 radiobuttons, un button ok, un autre annuler, un bouton refresh et la dite listview.

[DonQuiche]

Personnellement, je n'ai jamais rien observé de tel : une fois la liste construite, je ne vois pas pourquoi il y aurait consommation de CPU.

A mon avis, prends un peu de recul, songe à l'ensemble de ton code et tu trouveras ce qui ne colle pas. Mais je ne vois pas pourquoi la ListView serait en cause.

[soa]

Personnellement, je n'ai jamais rien observé de tel : une fois la liste construite, je ne vois pas pourquoi il y aurait consommation de CPU.

A mon avis, prends un peu de recul, songe à l'ensemble de ton code et tu trouveras ce qui ne colle pas. Mais je ne vois pas pourquoi la ListView serait en cause.

Ben le seul truc qui consomme du CPU sur cette fenêtre pour ainsi dire, c'est que chaque objet "Host", dont certaines infos sont justement placées dans l'item de la listview justement, lance chacun un thread.

Le thread que l'objet "Host" a créé est lancé de toute façon, que j'affiche l'item dans la listview ou pas!
Donc pourquoi si je n'affiche pas la listview la charge CPU est modérée, et si je l'affiche elle gonfle démesurément. Donc je ne pense pas que les thread soient en cause, donc du coup qu'est-ce qui peut consommer sur cette page, rien, il n'y a rien d'autre, à part la listview qui semble suspect dès que je la remplis.

[Nathanael Marchand]

Si tu as une version de Visual Studio un peu avancée tu dois avoir accès aux outils de profiling afin de faire des tests sur qui occupe le cpu et pourquoi.

[tomlev]

Ben le seul truc qui consomme du CPU sur cette fenêtre pour ainsi dire, c'est que chaque objet "Host", dont certaines infos sont justement placées dans l'item de la listview justement, lance chacun un thread.

Normalement les objets UI ne sont pas accessibles depuis un thread autre que celui de l'UI. Tu utilises Control.Invoke pour accéder aux données du ListViewItem ?

[soa]

Normalement les objets UI ne sont pas accessibles depuis un thread autre que celui de l'UI. Tu utilises Control.Invoke pour accéder aux données du ListViewItem ?

Le thread n'accède jamais à la listview. Les thread ne font que mettre à jour une variable de l'objet Host.
En gros l'objet Host (qui représente un PC sur le réseau), lance un thread qui vérifie périodiquement si le PC est toujours en ligne ou pas et met à jour un membre de la class Host.


Du côté de la fenêtre contenant la listview, je ne fais que créer mes objets Host, et pour créer la listview je ne fait que parcourir tous les objets Host et utiliser certaines infos pour l'affichage, dont l'état du PC (objet Host) présent dans une variable, variable que les thread respectifs auront mis à jour.


Ca peut poser problème?

[tomlev]

Ca peut poser problème?

A priori non, mais j'avais mal compris ce que tu expliquais... je croyais que les threads accédaient à des données placées dans les ListViewItems

[soa]

Si tu as une version de Visual Studio un peu avancée tu dois avoir accès aux outils de profiling afin de faire des tests sur qui occupe le cpu et pourquoi.

J'ai la version express. Mais je peux télécharger une version de test de la version complète si nécessaire.
Comment il s'appelle cet outil?

[Nathanael Marchand]

J'ai la version express. Mais je peux télécharger une version de test de la version complète si nécessaire.
Comment il s'appelle cet outil?

Dans le Menu "Analyze" y'a le sous menu "Profiler" et tu crées une session de profiling

[soa]

D'accord je testerai ca.

Merci

[soa]

Je viens de trouver la source du problème. J'en reviens toujours pas.

La listView contient 3 ListViewGroup. Ben je les enlève et plus de problème de surcharge CPU.

Non mais c'est dingue. Ces 3 ListViewGroup je les ai créé avec l'interface graphique de Visual Studio, j'ai juste donné un nom au header de ce group et rien d'autre.

Je précise aussi qu'il suffit que ces ListViewGroup soit ajoutés à l'objet listview pour avoir le problème. Même si ces groups ne sont pas affichés (car aucun item n'est dans ces group) ben ca bug quand même.


Je suis sur le cul là.

Ca m’embête parce que ca m'arrangeait bien ces groups.

[tomlev]

Bizarre... pourtant en cherchant "ListViewGroup performance" sur Google je trouve rien en rapport avec ton problème. J'essaierai de tester pour voir si ça fait pareil chez moi

[soa]

Bon alors je viens de créer une application à part.

Elle ne contient qu'une listview à 6 colonnes et 3 listviewgroup (j'ai pas encore testé avec d'autre valeurs).

Un bouton pour rajouter des item à la listview:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
            lv.BeginUpdate();
 
            ListViewGroup myGroup = lv.Groups[0];
            ListViewGroup myGroup2 = lv.Groups[1];
            ListViewGroup myGroup3 = lv.Groups[2];
 
            ListViewItem item = new ListViewItem();
 
            item.Group = myGroup;
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
            item.SubItems.Add("blabla");
 
 
            ListViewItem item2 = new ListViewItem();
 
            item2.Group = myGroup;
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
            item2.SubItems.Add("blabla");
 
            lv.Items.Add(item);
            lv.Items.Add(item2);
 
            lv.EndUpdate();

Et c'est tout, il a absolument plus rien d'autre.
Résultat?

Ca bug aussi, mais sous certaines conditions.

1.



2.


Notez la différence de charge CPU.
La différence entre ces 2 images? La scrollbar!!!

Dès qu'il y a trop de item et que la scrollbar apparaît la charge CPU augmente!!!


Par contre dans ma première application sur laquel je bossais et où j'ai eu le problème (d'ailleurs sur les 2 différents PC sur lesquels je bosse), je n'ai pas besoin que la scrollbar apparaisse pour avoir ce problème de surcharge cpu. C'est vraiment bizarre.


EDIT:
Ca le fait aussi avec une unique colonne et un unique groupe.

[tomlev]

J'ai fait le test, et même avec 10 colonnes et 10 groupes, j'ai pas vu de pic d'usage important du CPU... ça monte à 5% quand il y a 500 items, mais c'est pas vraiment choquant, et ça dure qu'une fraction de seconde (le temps de créer tous les items, quoi...)

EDIT: j'avais fait le test sous XP avec un Core i7 (8 coeurs logiques avec l'Hyperthreading), donc 5% du total ça représente environ 40% d'un coeur. Mais bon, si c'est juste pour l'affichage et que ça dure qu'une fraction de seconde, ça me semble toujours pas choquant.
Je viens de retester sur une VM sous Seven qui utilise un seul coeur, ça monte à 20% d'usage CPU avant de retomber à 0. L'usage remonte un peu à nouveau quand je scrolle, mais là encore rien d'anormal, et ça ne se ressent pas sur les perfs globales du système

Bref, de mon côté tout se passe plutot normalement...