Discussion :

[freerider74]

Bonjour à tous,

Je suis confronté à un problème pas facile à résoudre. Je développe une appli sur PDA et j'ai souvent des Out Of Memory qui apparaisse.

La question, comment faire pour que la mémoire soit libérée instantanément au moment ou l'objet est détruit

[Pol63]

gc.collect en théorie, mais y en a qui sont pas trop fans ...

[freerider74]

j'ai essayé mais cela n'a pas l'air de trop marcher. J'ai essayer d'utiliser aussi

GC.WaitingPendFinalize (je sais plus si c'est le nom correct)
mais rien à faire

[Pol63]

si gc.collect ne fait rien, je pense que tu as fait une fuite mémoire

il faut aussi compiler en release sinon c'est normal que la ram ne redescende pas trop

[MetalGeek]

Salut,
franchement ça dépend vraiment de ton code ; utilises-tu des ressources non managées, des stream, des images etc ? Si oui fait bien attention à appeler les Dispose(), à utiliser le mot-clé using etc.
Sinon, essaie d'utiliser là où c'est possible des singleton, des références faibles ; si l'appli est un peu compliquée, fais des diagrammes d'activité pour cibler les comportements potentiellement trés créationnistes et optimise la durée de vie des objets selon leur utilisation.

[freerider74]

Je vais détailler un peu l'appli.

Comme je l'ai jit dans mon premier post c'est une application PDA qui tourne sur Windows Mobile 6 avec le Compact Framework 2.0. Jusque là rien de bien exceptionnel.

C'est une appli GPS (qui lui ne pose aucun problème). Une base SQL CE est derrière. on fait pas mal d'appel mais de ce côté tous les objet sont bien détruits.

La grosse complication c'est que l'appli dessine beaucoup de bitmap.

La grosse question que je me pose c'est est-ce que une taille maximum d'utilisation de la mémoire est attribué à l'appli (genre pour l'appli le système décide de lui attribuer 10 Mo de mémoire)

Car dans le passé nous avons rencontré ce genre de problème et pour palier au problème nous avons fait un éxecutable à part. Et là plus aucun Out of Memory alors qu'on faisait la même sauf qu'on y avait mis dans un exe à part
(le code n'est pa
s de moi, je viens de reprendre le projet complet).

J'amerai bien en savoir un peu plus sur "les diagrammes d'activité pour cibler les comportements potentiellement trés créationnistes et optimise la durée de vie des objets selon leur utilisation".

Quelle différence y a t-il a utiliser les usings dans le code plutot qu'en en-tête de code.

Quelle grosse différence y a t'il entre un code générer en release plutot qu'en debug?

Et dernière chose qu'est-ce qu'in singleton.

[Pol63]

je ne pense qu'un OS limite une appli en mémoire au démarrage de celle ci
enfin windows mobile est peut etre différent ...
out of memory arrive quand y a plus de mémoire de dispo, donc soit si tu créé plus vite que tu ne détruits (le garbage collector s'occupe de détruire), soit si tu as des fuites mémoires (le mode debug est une fuite mémoire, comme je l'explique ci après)
le garbage collector est appelé par l'os quand la mémoire dispo se fait rare, il se met alors en chasse d'objets non utilisés pour les détruire
voir si windows mobile appelle bien le gc ...



il ne faut pas confondre les usings avec les imports
les imports ne servent qu'à eviter de taper trop de code (rien à voir avec les références du projet aussi)
using est un mot clé avec desctruction implicite et gestion de l'interface IDisposable

Code :

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

1
2
3
4
 
using b as new bitmap(largeur,hauteur)
  'traitement sur b
end using

using fonctionne avec tout type de variable, il est conseillé sur toutes celles qui implémentent IDisposable
quand le code sort du using/end using, la variable est détruite, et Disposée si elle le permet
et ce meme si ca sort par une erreur d'execution, alors que si tu écris

Code :

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

1
2
3
4
 
dim b as new bitmap
'traitement sur b
b.dispose

et que pendant le traitement sur b il y a une erreur, b.dispose n'est pas exécuté

par contre le garbage collector arrivera quand meme à le disposer, donc pas de fuite réelle possible, le framework est bien sécurisé

c'est un peu comme finally dans un try catch, ca sera fait dans tous les cas


pour la différence entre debug et release :
microsoft interdit de déployer des applis compilés en mode debug
le mode release compile le code en l'optimisant, en changeant même parfois le code avec un effet similaire mais plus de perfs
en mode release la compilation est axée sur le debugage, très utile avec un debugger tel visual studio, il est alors possible de modifier le code pendant l'execution, de voir le contenu de certaines variables meme hors du champs d'action de celle ci
le mode debug garde un lien vers chaque variable, pour aider au débuggage
en mode debug, une application est donc par définition une fuite mémoire !


pour les singletons
c'est pas toujours utile, ca permet d'avoir une classe qui ne peut être instanciée qu'une seule fois
le sub new n'est pas accessible et on obtient l'instance via une fonction shared

Code :

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

1
2
3
4
5
6
7
8
9
10
public class MaClasse
  private sub new
  end sub
 
  private shared _instance as MaClasse
  public shared function GetInstance() as MaClasse
    if _instance is nothing then _instance = new maclasse
    return _instance
  end function
end class

après il faut en avoir l'utilité ...

[MetalGeek]

using fonctionne avec tout type de variable

Sauf erreur de ma part, 'using' est utilisable uniquement sur les types implémentant IDisposable ; en fait c'est traduit en MSIL par exactement l'équivalent d'un try/finally avec l'appel à Dispose() dans le finally.
Pour les singleton, ça peut être très utile si tu utilises des objets 'support' (ex. un créateur d'objet, un convertisseur etc) qui ne maintiennent pas d'état spécifique. Ainsi selon les scenarios au lieu d'avoir des centaines d'instances avec le singleton tu n'en a qu'une.
Mais si ton appli créé beaucoup d'images, le 'out of memory' vient très certainement de là. Soit il y a des ressources non libérées, soit tu créés des bitmap de toutes pièces (sans les charger depuis des fichiers) et certains paramètres sont impropres (dpi ou stride trop importants par exemple).
As-tu essayé le même code version windows de bureau ? Si oui y-a-t-il le même problème ?

[freerider74]

il ne faut pas confondre les usings avec les imports

désolé, étant un habitué du c# j'ai fait une petite confusion entre vb.net et c#

Soit disant passant, je pourrai controlé mon code que demain, en tous cas merci pour votre aide

Je vais voir pour utiliser les using sa me parrai etre un bon procéder

Je vous tiens au courant

[Pol63]

pour les bitmaps, si tu peux les faire en 16bits au lieu de 32bits par exemple, ca prendrais 2x moins de mémoire
et les matériels sous windows mobile aujourd'hui manque souvent de mémoire ...

Sauf erreur de ma part, 'using' est utilisable uniquement sur les types implémentant IDisposable

ah oui en effet, je croyais que si ca n'implémentait pas ca faisait certes rien de spécial, mais que ca limitait au passage un bloc pour les variables,
mais le compilateur n'en veut pas, et puis en plus ca serait pas logique que ca délimite une pourtée, car using peut etre utilisé avec une variable déclarée dans le bloc extérieur ...

[freerider74]

ouais mais en passant mes images 32 bits en 16 bits, je ne risque pas de perdre beaucoup en qualité d'image

[Pol63]

24 alors ca reste beau et ca fait 25% de moins ...

[freerider74]

Petit truc. Vendredi j'avais commencé quelque test avec le Remote Performance Analiser. Si jamais j'avais une fuite de mémoire je devrais le voir avec cet outils non?

[freerider74]

Me revoilà avec des nouvelles. Apparement le probleme c'était pas du a une fuite mémoire mais plutot à des vidéos un peu gourmandes, après ré-encodages des vidéos, plus de problèmes en particulier. Je vous remercie pour votre aide qui m'a permis d'apprendre des choses intéressantes.