Cela peut provenir des objets non détruit dans un process réccurent, ce qui peut faire gonfler la mémoire considérablement si
les objets générés consomment beaucoup de ressources (souvent des datastores ou datawindows généralement)

Nous avons déjà rencontré ce genre de problèmes que nous avions corrigé temporairement en utilisant la fonction GarbageCollect( ) qui provoque la destructions des objets en mémoires qui ne sont plus utilisés.

Le plus difficile est de localiser le process qui provoque ce gonflement de mémoire...

A+

Vincent

Garth a écrit:

Avez vous des trucs et astuces pour identifier les process ?

Exécuter le programme pas à pas et observer l'évolution de la mémoire utilisée dans le gestionnaire de tâches.

Le même problème chez nous était lié à la création/destruction d'un nombre très important de datastores... la mémoire n'étant pas complètement libérée par PB à chaque destruction, elle gonfle anormalement.

Vous n'auriez pas des boucles dans lesquelles des datastores sont créés puis détruits (ou même pas détruits du tout !) ?

Essaye de limiter le nb de DS, par exemple ne pas les créer à chaque passage dans la boucle mais les créer hors de la boucle et les réinitialiser à chaque passage dans la boucle.

Bonjour,

J'ai également remarqué qu'une datastore passé en argument d'une méthode ou d'une fonction par valeur augmente la mémoire occupée puisque les données sont dupliquées (logique).
Mais, cette mémoire n'est pas correctement libérée en sortie de fonctions (PB 11.2).

S'il n'y a pas d'impacts (datastore utilisée en lecture par exemple), il est préférable de passer par référence les datastores. Cette petite modification dans notre application a eu une large impact sur la mémoire occupée surtout lorsqu'un large volume de données est concernée.

Bonjour,

Oui, j'ai été un peu approximatif. En fait, pour les objets, il devrait toujours être passé par référence même si l'argument de passage est de type value (Il devrait s'agir d'un pointeur sur 32 bits je suppose).

J'ai constaté un large changement de comportement selon que le passage est de type value ou reference. Par reference, on constate aucun changement de l'occupation mémoire tandis que par value on a l'impression que l'occupation mémoire s'accroit selon la quantité de données "on a l'impression qu'il y a une duplication des données". J'admet que pour un objet, on devrait s'attendre à un comportement strictement identique dans les 2 cas, mais ce n'est pas le cas dans la réalité.

Nous avons réglé simplement des gros problèmes d'occupation excessive de la mémoire en modifiant simplement le type de passage d'arguments de "value" à "reference". Ceci est effectivement à prendre au conditionnel, ce problème était peut être spécifique à la version de Powerbuilder que nous utilisions à l'époque à vérifier sur d'autres versions, certaines versions de Powerbuilder sont connues pour leur "memory leak".

Je reviens sur le post pour dire qu'on a finit par trouver l'origine de notre problème...
notre appli est affichée sur chaque poste sur 2 écrans.
dans l'appli, on gérait une variable de type array dans laquelle on stockait une ino spécifiant si la fenêtre était ouverte sur l'écran de gauche ou sur l'écran de droite du type gs_fenetre_ecran[x] = 'D' ou 'G'. Or, on utilisait comme index du tableau le handle de la fenêtre que nous renvoyait windows pensant que PB créait uniquement en mémoire la référence à l'index spécifiée....
L'erreur dans notre raisonnement c'est que si on créé un tableau avec un index x, PB lui créé pas un tableau de 1 élément mais un tableau de x élément, même si les élément de 1 à x-1 ne sont pas renseigné. et comme Windows renvoie des handles immenses du 15984420 on se retrouvaient avec des tableaux énormes qui explosaient la mémoire.

Voilà pour la petite histoire... Ca peut servir ;-).