[OnPropertyChanged] Fuites mémoire

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/10/2010, 09h29
stailer

[OnPropertyChanged] Fuites mémoire

Salut,

J'ai posté un message il y a quelques temps sur les performances... Après quelques réponses qui m'ont aiguillé je peux me rendre compte aujourd'hui que mes gros soucis de fuites mémoire sont liés au "OnPropertyChanged" (je dois encore faire des tests pour vraiment en être sur).

En effet, j'ai une fenêtre très très chargée en composants (100 environ dont 2 DataGrid Telerik) et beaucoup de liaisons et d'appels dynamiques entre eux.

En enlevant simplement l'appel à mes ObservableCollection en OnPropertyChanged il me faut au moins 100 clics entre ma fenêtre d'accueil et cette fenêtre pour passer de 100 megs à 200 megs (processus IExplorer dans le gestionnaire des tâches).

En les réactivant : au bout de 12 clics je suis à 200 megs et ça freeze méchamment.

Ma question : l'un d'entre vous aurait-il concrètement implémenté un pattern genre WeakEvent que j'ai du mal à comprendre pour le moment ?

A part ce pattern (en espérant qu'il fonctionne bien), connaissez vous d'autres solutions pour "vider" la mémoire ? j'ai essayé le GC mais rien ne se passe...

Merci pour vos réponses,
16/10/2010, 17h56
Samuel Blanchard

La bonne solution sera d'implémenté pour chaque += un -=.
En pratique je n'implémente jamais de WeakEvent :)

ok ça je l'ai fait plus ou moins mais je me suis mal expliqué... Je parle ici des propriétés, pas des événements. Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 private ObservableCollection<clients> _clients; public ObservableCollection<clients> AllClients() { get { return _clients;} set { _clients = value; OnPropertyChanged("AllClients"); } }
Je suis en MVVM et cette propriété est appelée par binding directement dans un contrôle d'une vue, par exemple un datagrid :
Code:

1 2 ItemsSource={Binding AllClients, Mode=TwoWay}
Donc te concernant tu as également des forms avec une bonne 100ene de composants mais pas de souci de fuite mémoire aussi énorme ?

Non pas de problème de fuite. Le souci que tu rencontres ici est que ta gestion de collection n'est pas complète.

Code:

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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
private ObservableCollection<Client> _clients;
 
public ObservableCollection<Client> AllClients()
{
    get { return _clients;}
    set {
 
         if( _clients != null )
         {
             // on désabonne l'ancien objet
             value.CollectionChanged -= new NotifyCollectionChangedEventHandler(AllClients_CollectionChanged);
         }
 
         _clients = value;
 
         if( value != null )
        {
             // on abonne le nouvelle objet
             value.CollectionChanged += new NotifyCollectionChangedEventHandler(AllClients_CollectionChanged);
        }
    }
}
 
private void AllClients_CollectionChanged( object sender, System.Collections.Specialized.NotifyCollectionChangedEventArgs e)
        {
            switch( e.Action )
            {
                case NotifyCollectionChangedAction.Add :
 
                    foreach (Client client in e.NewItems)
                    {
                        client.PropertyChanged += new PropertyChangedEventHandler(ClientPropertyChanged);
                    }
 
                    break;
 
                case NotifyCollectionChangedAction.Remove:
                    foreach (Client client in e.OldItems)
                    {
                        client.PropertyChanged -= new PropertyChangedEventHandler(ClientPropertyChanged);
                    }
                    break;
            }
        }
 
        void ClientPropertyChanged(object sender, PropertyChangedEventArgs e)
        {
            Client client = sender as Client;
 
            switch( e.PropertyName )
            {
            }
        }

Je te conseille d'ecrire un snippet de ce type de collection qui, certe, est un peu lourd mais indispensable pour ne pas tomber dans le piège des memoryleaks ;) Si tu veux je peux t'envoyer le mien.

17/10/2010, 14h08
stailer

Ah oui... la c'est du lourd..

je vais donc changer mes propriétés dès demain et tester ça.
Ca m'embête un peu mais bon.. 30 lignes de code pour 20 propriétés ça fait 600 lignes. Heureusement qu'on a les region :aie:

Merci beaucoup pour ta réponse qui je pense va m'enlever une grosse épine du pied. je te tiens au courant.
17/10/2010, 20h15
Skyounet

Citation:

Envoyé par Samoteph

Non pas de problème de fuite. Le souci que tu rencontres ici est que ta gestion de collection n'est pas complète.

Hum je vois pas en quoi ton bout de code va l'aider...

A quoi bon s'abonner à CollectionChanged et à PropertyChanged si on ne fait rien dedans ? :koi:

Qu'entends-tu par : "pas complète" ?
Si son but est d'exposer simplement une ObservableCollection, ça sert à quoi de s'abonner au CollectionChanged puis à chaque PropertyChanged de chaque item de cette collection ? (par ailleurs tu ne t'abonnes pas au PropertyChanged des items présents dans la collection à l'assignation, seulement aux éléments rajoutés par la suite).

J'ai peut-être pas compris ce qu'il demande mais bon.
17/10/2010, 20h37
Samuel Blanchard

Citation:

A quoi bon s'abonner à CollectionChanged et à PropertyChanged si on ne fait rien dedans ?

Le but etait de montrer comment on s'abonne proprement à PropertyChanged à l'intérieur d'une collection. Après je ne connais pas ce qu'il veut faire dedans. C'est à lui de rajouter sa propre gestion de propertyChanged

Citation:

Qu'entends-tu par : "pas complète" ?

Quand on fait un += proprement on fait normalement un -=

Citation:

Si son but est d'exposer simplement une ObservableCollection, ça sert à quoi de s'abonner au CollectionChanged puis à chaque PropertyChanged de chaque item de cette collection ?

Si j'ai bien compris le problème de Stailer, il a besoin de gérer les PropertyChanged dans une ObservableCollection proprement afin d'éviter des memoryleaks. Pour que les élements ajoutés/retirés de la collection prennent en compte l'evenement PropertyChanged, il faut bien s'abonner à CollectionChanged.

Citation:

(par ailleurs tu ne t'abonnes pas au PropertyChanged des items présents dans la collection à l'assignation, seulement aux éléments rajoutés par la suite).

c'est vrai j'ai oublié dans mon exemple. Je l'ai écris un peu à l'arrache :aie:
18/10/2010, 09h17
Samuel Blanchard
Stailer,

pour que la mise en place soit plus simple dans ton projet, je pense que tu dois pouvoir creer une classe dérivé de ObservableCollection qui prend comme paramètre de constructeur et/ou propriété un delegué sur la méthode propertyChanged à éxecuter. un truc du genre :
Code:

1 2 3 4 ObservableCollectionPropertyChanged c = new ObservableCollectionPropertyChanged( (s, e) => { MessageBox.Show("PropertyChanged de la propriété " + e.PropertyName); });
18/10/2010, 10h48
Samuel Blanchard

En relisant ton message de départ, je me demande si je n'ai pas mal interprété ta demande :aie:

Je sais que Silverlight 4 avait des problèmes de MemoryLeaks avec les DataTemplates notamment. La dernière release datant de septembre 2010 corrige ces problèmes. Es-tu à jour ?

http://timheuer.com/blog/archive/201...2010-gdr1.aspx

Salut,

Merci encore pour l'intérêt que tu portes à mon poste.
La page que tu me donnes est introuvable mais j'ai l'impression que le blog de Tim Hauer a des soucis depuis quelques jours ;)

Pour répondre à Skyounet sur ce que "je veux faire de mes observablecollection" : ben tout simplement les envoyer des datagrid qui sont bindées dessus.

Voici un exemple concret de mon code pour "nourrir" ce binding :
Code:

1 2 3 4 5 6 bddContext.Load<SimpleLieuxLivraison>(bddContext.getLieuxLivraisonByIdCollectiviteQuery(Locator.getMainViewModel.SelectedCollectiviteExercice.uidcollectivite), loB => { this.ListeLieuxdeLivraison = new ObservableCollection<SimpleLieuxLivraison>(loB.Entities); }, true);
Voilà, j'utilise donc WCFRiaServices.. et à chaque fois que je vais passer dans le code ci dessus ce sont 4 ou 5 megs que prend le navigateur dans la tête... Et qui ne se vide pas. Donc le passage à nouveau ici remet 4 ou 5 megs etc etc..

donc ceci : this.ListeLieuxdeLivraison , je cherche à le vider et le réinitialiser correctement pour que la mémoire ne soit : ou pas cumulée ou correctement nettoyée à chaque fois.

Et pour l'instant, autant dire que je n'y arrive pas :aie:

Pour vous montrer encore plus le problème :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 loB =>
                {
                    if (this.ListeLieuxdeLivraison != null)
                    {
                        this.ListeLieuxdeLivraison.Clear();
                        this.ListeLieuxdeLivraison = null;
                    }
 
                    this.ListeLieuxdeLivraison = new ObservableCollection<SimpleLieuxLivraison>(loB.Entities);
 
                    MessageBox.Show(GC.GetTotalMemory(true).ToString());
                }, true)

J'ai essayé ça mais rien n'y fait le messagebox montre clairement que la mémoire augmente, augmente...

18/10/2010, 13h50
Thomas Lebrun

Tu récupère combien d'entités dans loB.Entities ?
18/10/2010, 13h59
stailer

Maxi 50... C'est un petit celui la.
j'en ai des plus volumineux mais ça dépasse pas les 500.
Pour mes tests j'ai désactivé tous les autres. J'essaye de régler le problème pour 1 puis après j'appliquerai aux autres.

Je suis vraiment ennuyé avec ça et je suis surpris qu'aucun d'entre vous aient le souci.. Je vais continuer de chercher ..
08/01/2011, 00h10
Manu-F

INotifyDataErrorInfo - fuite mémoire

Salut,

Si tu cherches toujours, as-tu regardé du côté de la fuite mémoire due à l'implémentation de INotifyDataErrorInfo dans les entities de RIA Services? C'est surement le problème que tu rencontres.

http://www.baud.cz/blog/memory-leak-...ydataerrorinfo

La classe Entity implémente l'interface INotifyDataErrorInfo. Lorsqu'on bind une entité sur une propriété d'un controle, par défaut, le framework rajoute un handler (NotifyDataErrorHandler je crois) sur l'objet. Cela crée une référence vers ce controle qui ne sera jamais enlevée... Résultat: pour peu que tes entités persistent, le controle n'est jamais éliminé par le GC.

Pour binder quand même une entité à un controle, tu peux contourner le problème en rajoutant dans les propriétés du Binding:

Code:

{Binding Path=MyProperty, ... , NotifyOnValidationError=False}

Malheureusement, dans certain, cas ce sera pas suffisant, notamment avec les collections d'entités liées à des ItemsControls et autres controles de liste.

Le mieux reste de passer par des POCOs qui n'implémenteront pas l'interface en question ou d'attendre une correction dans la prochaine version de Silverlight.

En espérant que ça t'aide.
09/01/2011, 22h51
stailer

Je te remercie pour ton aide mais pour l'instant, et après avoir faits différents tests d'équivalence grâce à un ami passionné de Flex4, je me rends à cette évidence :

Silverlight est lourd, trèèès lourd. Pour une application complexe de plusieurs 10ènes de forms complexes et avec des composants étendus ou tiers, je ne suis pas encore sûr de la réalité d'un dev d'une VRAIE et grosse appli de gestion avec cette techno.

A suivre avec SL5...
10/01/2011, 08h23
Samuel Blanchard

J'ai participé au développement d'un portail de gestion assez lourd en Silverlight et cela se passe très bien.

En revanche, impossible de comparer avec Flex4 que je ne connais pas du tout.
10/01/2011, 10h49
stailer

Citation:

J'ai participé au développement d'un portail de gestion assez lourd en Silverlight et cela se passe très bien.

Ok, alors petit test simple, le même que nous avons réalisé :

1 - fais une appli Silverlight de type navigation
2 - Ajoute sur la page accueil 3 ou 4 datagrids réceptionnant des données + divers contrôles qui ne font rien : des tabs, des boutons... bref mets en un max à l'écran
3 - dans une autre page fais la même chose

C'est tout.

Maintenant lance ton appli , ouvre les processus windows et regarde celui d'internet explorer . Commence à naviguer entre les pages :
Page1, page2, Page1, Page2 etc...

Testé sur 6 ordis environ :

La mémoire augmente, augmente et ne descend jamais ou vraiment très peu.
Reprend la navigation en cliquant pleins de fois sur les pages.

Regarde de nouveau le processus : Ca augmente et ça n'a de cesse d'augmenter.

Conclusion :
Alors évidemment sur une appli comme ça, ça va... de 70-80 megs tu vas passer à 110.
Mais sur une appli comme j'ai pu commencer à le faire, avec 3 écrans recevant des 10ène de binding.. de 130 megs au chargement tu vas rapidement passer à 300, 400 (bien sur les composants Telerik n'y sont pas pour rien).

Et ça fini par le crash ...

Si tu n'observes pas ce même type de problème, alors je recevrai avec plaisir ta solution en zip pour la tester ;)

Citation:

En revanche, impossible de comparer avec Flex4 que je ne connais pas du tout.

Ben c'est fait :
Dans notre test une des pages (en Flex4 donc) faisait des traitements très lourds et effectivement le processus montait.
Mais après quelques secondes, le GC passe et vide une bonne partie.
Nous étions à 120 megs.
Sur le clic d'une autre page alors la, le GC vidait carrément tout et nous repassions à 80 megs, ce qui était presque la valeur au chargement de l'appli.
10/01/2011, 11h17
Samuel Blanchard

Citation:

Si tu n'observes pas ce même type de problème, alors je recevrai avec plaisir ta solution en zip pour la tester

En l'occurrence, je prefererai plutot tester ton application (celle qui pose problème).
10/01/2011, 12h02
stailer

Je ne peux pas te passer l'appli qui est confidentielle.

Par contre je peux rapidement te refaire un projet, c'est vite fait.
Je te tiens au courant par MP dès que j'ai 5 minutes pour faire tout ça .

Eventuellement je ferais une vidéo avec wink.
10/01/2011, 13h56
Samuel Blanchard

Ca me va bien.Le mieux serait de poster le projet sur le forum afin qu'on puisse regarder ensemble :)

Voir 40 message(s) de cette discussion en une page