Discussion :

[petitours]

Bonjour

Dans mon appli Winform je remplis des listes avec des données lues dans des gros fichiers CSV afin de pouvoir manipuler les données plus rapidement ensuite.

Là j'ai traité un cas qui a rempli 100% de ma RAM, le traitement a fortement ralenti pour les listes remplies après que la RAM eu été remplie...sans planter.
J'en déduis donc que mon truc est sain vu qu'il arrive à fonctionner même quand le pc est à genoux mais je m’interroge sur ce qui se passe vraiment une fois la RAM pleine.

Y a t-il une autre limite ? cela va fonctionner tant que mon DD système n'est pas rempli ?

Merci

[PatteDePoule]

Je dirais que lorsque l'OS n'arrivera plus à trouver d'espace dans la mémoire vive ni dans le mémoire virtuelle il risque de ce passer quelque chose de pas très net.

[DonQuiche]

Y a t-il une autre limite ? cela va fonctionner tant que mon DD système n'est pas rempli ?

Une fois la mémoire pleine Windows va utiliser ce qu'on appelle le fichier d'échange (swap file, parfois appelé abusivement "mémoire virtuelle"). Il est nommé ainsi parce que Windows ne travaille pas directement depuis ce fichier mais fait plutôt passer les pages mémoire de la mémoire au disque en fonction des demandes.

Ce fichier a, dans les paramètres par défaut du système d'exploitation, une taille maximale bien définie, généralement du même ordre de grandeur que la mémoire. Quand tu arriveras au bout tu auras la joie d'obtenir une OutOfMemoryException. Et même si tu l'attrapes une autre sera vraisemblablement relancée dès la prochaine tentative d'allocation.

Cela dit à mon avis tu auras plus vite fait d'atteindre une autre limite, celle des 2Go mis à disposition des programmes 32 bits (2^31 = 2 milliards). A moins que tu ne sois sur un OS 64 bits ET que tu aies expressément déclaré que ton application utilise un adressage 64-bits.

[petitours]

Bonjour

Merci pour ces explications forts intéressantes.
Je suis sur une machine 64bit, je n'ai à priori pas spécifié explicitement que je voulais une appli 64bit (je m'en souviendrais) mais pourtant il me semble bien que j'ai dépassé ces 2Go en mémoire lors de mon gros chargement d'hier.
Mon PC est sous seven 64bit avec 4Go de mémoire physique. Mais bon je ne comprends pas trop ce que windows me raconte dans l'onglet performance du gestionnaire de périphériques.

Comment puis-je vérifier cela ?
Ça me parait important d’être au clair avec ça avant d'aller plus loin parce que sinon je vais me retrouver avec une application structurellement incapable quand je serai sur des gros traitements.

Merci

[DonQuiche]

En toute franchise j'ai un doute sur la façon dont la version actuelle du compilo dotnet active ou non le 64 bits. Je sais que se mettre en "any cpu" sur un OS x64 ou "x64" sur n'importe quel OS déclenche certains changements mais je ne sais pas ce qu'il en est exactement. Je me mélange un peu entre le vrai x64 et le support de 3Go sur XP.

Fais un test avec 5Go (alloue 5 tableaux de 1Go et stocke-les dans des variables statiques) et tu verras bien.

[Graffito]

Est-ce que tu libères des listes pendant le traitement ?

Dans ce cas, il faudrait peut-être forcer le garbage collector à récupérer de la mémoire. J'ai mis un bout de code C# dans cette discusion : http://www.developpez.net/forums/d12...orm-net-2-0-a/

[petitours]

Bonjour

Je n'ai pas eu le tempsde faire tous les essais encore
je vais tester sur ma machine seven 64bit puis sur un XP 32bit pour voir

Mes listes ne sont pas libérées puisque le but est de les charger au chargement du fichier puis de bien les garder au chaud pour pouvoir les manipuler (regarder tout ou partie des données pleins de fois.

[DonQuiche]

Est-ce que tu libères des listes pendant le traitement ?

Dans ce cas, il faudrait peut-être forcer le garbage collector à récupérer de la mémoire. J'ai mis un bout de code C# dans cette discusion : http://www.developpez.net/forums/d12...orm-net-2-0-a/

Je suis désolé mais je dois essentiellement te contredire, ne le prends pas personnellement :

a) En cas de pénurie de mémoire la CLI procède déjà à un ramassage des miettes avant de retenter l'allocation. Et c'est seulement si cette seconde tentative échoue qu'une OutOfMemoryException sera lancée. Inutile de nettoyer manuellement.

b) Le code que tu as donné dans l'autre thread ne sert de toute façon pas à "forcer un nettoyage" (ce qui serait inutile) mais à récupérer après l'échec d'une allocation impossible, en renonçant à celle-ci (par exemple pour notifier l'utilisateur d'un pb).

c) Cette façon de faire où l'on cherche à attraper l'exception est par ailleurs inadaptée au multithreading (si ton allocation a fait échouer ton thread courant il est plausible que les autres threads vont échouer avant que tu n'aies eu le temps de nettoyer) et à un environnement hébergé type SQL Server (une OOM dans une région critique cause la mise à mort du domaine d'application sans préavis). MemoryFailPoint est fait expressément pour ça.

d) Les "fuites mémoires" en C# proviennent presque toujours des événements parce que le programmeur tend à oublier qu'en souscrivant à un abonnement il ajoute son objet à une liste et ne fais donc rien pour l'en retirer à la fin. Pas d'une paresse du GC (qui peut effectivement être paresseux mais sait se bouger quand nécessaire).

e) A la rigueur il y avait dans les versions précédentes du framework un pb avec la LOH (large objet heap) qui n'était pas compactée et dont la fragmentation pouvait gâcher de l'espace. Mais GC.Collect n'y changeait rien et il fallait soir recycler les grandes listes (> 80ko) soit redémarrer le processus.