Discussion :

[FrancisSourd]

Avant de faire un long calcul, je fais une série de prétraitement que je stocke comme une List<Info>. J'utilise ensuite les informations de type Info lors de mon calcul.
A l'exécution, lors de la construction de ma List<Info> "l'historique de l'utilisation du fichier d'échange" (dans le gestionnaire des tâches) croît doucement. En revanche, dès que je commence à utiliser mes informations stockées dans la phase "calcul", la mémoire "explose", ce qui me paraît paradoxal car le calcul ne stocke plus guère de nouvelles données lors de la phase de calcul.
Quelqu'un aurait-il une explication? un remède? Est-ce le garbage collector qui est affolé pour rien?

Pour info: j'utilise C# et .NET 2.0
Ma structure List<Info> contient 5000 à 10000 tableaux et chaque tableau contient 100 à 200 références (les objets référencés ne sont pas dupliqués).

[Thomas Lebrun]

La, sans code, je peux pas trop te dire ce qui va pas

Tu n'aurais pas une boucle infinie ou un truc du genre qui traine :

[NicolasG]

Ca paraît normal si beaucoup d'objets temporaires sont créés dans des boucles de calcul.
Ces objets sont détruits par le GC avec un certain retard, ce qui fait que la consommation mémoire augmente.

Si ça ne provoque pas d'erreur et que le programme se termine normalement, aucun problème.

[FrancisSourd]

Non, il n'y a pas de problème de type "boucle infini". Le programme fonctionne très bien... pour des problèmes de petite taille. Ce qui me paraît bizarre, c'est que le fait d'avoir allouer un gros bloc de mémoire fait oublier au GC de faire son travail lors de la phase de calcul.
Autrement dit, on note P la mémoire utilisée par le prétraitement et C la mémoire utilisée par le calcul en ne faisant pas le prétraitement. Lorsque le calcul se fait après le prétraitement, la mémoire consommée est très largement supérieure à C+P.

[bilb0t]

Tu as bcp de méthode récursive ?

[FrancisSourd]

Tu as bcp de méthode récursive ?

Oui, le calcul est une procédure récursive. Est-ce cette récursivité qui gênerait le GC?

[bilb0t]

Probablement puisqu'il va probablement crée énormément de variable locale qu'il ne pourra détruire qu'une fois que la récursion est finie.

Ton object ds lequel tu fais tes prétraitements, tu le passes chaque fois à ta méthode récursive ?

[FrancisSourd]

Je ne pense pas que cela soit dû à la récursivité (l'info dupliquée lors de la récursivité est très limitée).

En fait, je commence à avoir une petite idée sur la chose. Le précalcul accélère, le calcul (c'est son rôle!). Mais, comme le calcul devient plus rapide, il y a beaucoup plus d'allocation/désallocation à la seconde et c'est pour cela que le GC a du mal à suivre. Peut-être aussi parce que la mémoire est plus occupée, la phase de collecte est moins aisée... Je crois que je vais faire une gestion maison de l'allocation de ces petits objets fréquemment alloués/désalloués.

[NicolasG]

Je n'ai pas bien compris le problème.
L'application consomme juste beaucoup de mémoire ou ne fonctionne plus du tout ?

[Maniak]

Question bête : les objets en question, il y a quoi dedans ?
Parce que d'après tes chiffres, ça fait entre 500000 et 2 millions de ces objets à charger en mémoire en même temps. S'il y a 1ko par objet... :)

Et 'la mémoire "explose"' ok, mais pareil, tu as des chiffres ? :)

Et... si les objets sont petits, pas des structures, et que la conso de mémoire est bien plus grande que ce qui est dans les tableaux, va falloir montrer du code (classe Info et phase 'calcul', là où la mémoire est censée faire un bond :)

[FrancisSourd]

Je n'ai pas bien compris le problème.
L'application consomme juste beaucoup de mémoire ou ne fonctionne plus du tout ?

Elle consomme beaucoup de mémoire. La mémoire utilisée dépend de la taille du problème traité. Sur ma machine, on manque de mémoire à partir de la taille n=200 (n est le nombre de noeuds dans un graphe). Jusqu'ici, il n'y a pas de problème, tout est logique.

Mon problème vient du fait que si je lance mon calcul sans le prétraitement, il consomme de la mémoire en quantité C.

Si je fais le calcul avec le prétraitement, le prétraitement utilise de la mémoire P puis le calcul utilise une mémoire C'.

Les deux codes de calcul sont identiques au niveau des objets créés. En effet, la seule différence est qu'on évite de faire un calcul (un tri) dans le second cas, ce qui ne crée rien en mémoire. On pourrait donc supposer qu'on a C et C' sensiblement égaux. Or C' > C.

Les chiffres (pour un graphe de 100 tâches)
C = 140Mo (l'utilisation varie à cause des allocations/désallocation, cette valeur correspond au maximum d'utilisation pendant le calcul).
C' = 42Mo (le max aussi)
P = 34Mo (la mesure correspond bien à la taille théorique des infos stockées)

[FrancisSourd]

Question bête : les objets en question, il y a quoi dedans ?
Parce que d'après tes chiffres, ça fait entre 500000 et 2 millions de ces objets à charger en mémoire en même temps. S'il y a 1ko par objet...

Chaque Info contient un tri des arêtes d'un graphe selon un critère donné. Info contient donc un tableau d'arêtes.

Pour un graphe de 100 tâches, il y a 1455 arêtes soit 5820 octets.
On retient 6064 tris (List<Info>.Count), cela fait donc 34465Ko (c'est ce que je mesure par System.GC.GetTotalMemory(true)

Et 'la mémoire "explose"' ok, mais pareil, tu as des chiffres ?

Et... si les objets sont petits, pas des structures, et que la conso de mémoire est bien plus grande que ce qui est dans les tableaux, va falloir montrer du code (classe Info et phase 'calcul', là où la mémoire est censée faire un bond

Le code est évidemment trop long pour être posté... Je n'ai pas essayé de le reproduire sur un bout de code minimal. Je peux envoyer mon code aux personnes que cela intéresserait.

[FrancisSourd]

En forçant des System.GC.Collect() très régulièrement lors de mon calcul, la valeur C' reste toute petite (<1Mo) et P, bien sûr, ne bouge pas. En revanche, le temps de calcul est (bien sûr) grandement rallongé (x10).
Voici une petite expérience qui me renforce dans l'idée du fonctionnement du GC: lorsqu'il y a beaucoup de mémoire utilisé par le processus, le GC semble se déclencher moins souvent. Etes-vous d'accord?

[NicolasG]

lorsqu'il y a beaucoup de mémoire utilisé par le processus, le GC semble se déclencher moins souvent.

Mon impression est plutôt que le facteur déterminant est la charge processeur puisque le GC s'exécute dans un autre thread.

Le point interessant est la réaction du GC quand l'occupation mémoire requise excède la capacité disponible. Que se passe-t-il dans ce cas ?

[FrancisSourd]

Mon impression est plutôt que le facteur déterminant est la charge processeur puisque le GC s'exécute dans un autre thread.

C'est intéressant comme interprétation. En fait, mon calcul utilise 100% de mon unique processeur (qu'il y ait le précalcul ou pas). Est-ce que cela veut dire que le GC se ferait en parallèle (voire plus fréquemment) si j'avais 2 processeurs? ou un dual core?

Le point interessant est la réaction du GC quand l'occupation mémoire requise excède la capacité disponible. Que se passe-t-il dans ce cas ?

Là, Windows devient quasi-inutilisable: le calcul s'interrompt régulièrement (la charge du processeur descent à 0%) et il y a de nombreux accès disque. Est-ce bien ce qu'on appelle le swap disque qui se met en route?

[neguib]

Je me permet de relancer votre sujet pour savoir si votre souci a évolué ou si vous avez trouvé des réponses à certaines de vos interrogations.

[FrancisSourd]

Je me permet de relancer votre sujet pour savoir si votre souci a évolué ou si vous avez trouvé des réponses à certaines de vos interrogations.

Je n'ai rien trouvé d'extrèmement satisfaisant. J'ai toutefois modifié mon code pour éviter la création d'objets temporaires (deux double au lieu d'un objet vecteur), ce qui limite l'activité du GC.
J'ai aussi fait tourner mes tests sur une machine qui a plus de mémoire (et là, le problème ne se posait plus du tout!