Reprise du message précédent :
Au passage nraynaud te l'a dit, appeler GC.Collect() peut effectivement libérer plus vite la mémoire (mais elle le sera de toute façons), mais ça se paye en temps d'exécution. L'opération de garbage collecting n'est pas gratuite. C'est expliqué dans l'article de Richter.

mais même, son application ne peut physiquement pas utiliser seulement 2Mo de mémoire, faut être réaliste

 
Oui, mais comme conseillé dans cet article, je ne l'emploie qu'aprés des libérations massives d'objets (déconnexion du client, libération des ressources), quand il n'y a plus vraiment autre chose a faire. Donc pas de souci pour les perfs.
 

Sisi, j'ai bien compris.

J'ai un peu le même problème dans une appli serveur qui génère des PDF par batch (une application "serveur PDF" qui récupere des infos en B2D, remplie un objet avec ses infos et le "passe" à une fonction de génération de fichier PDF).
 
La mémoire augmente perpetuellement et n'est jamais "relachée".
Lorsquelle est relachée, c'est seulement la mémoire vive. Le fichier d'échange reste toujours à sa valeur précédente et lorsque l'on relance  un traitement, il continue de monter !
 
A terme, cela aboutit à un crash système d'allocation de ressource (soit crash windows mémoire swap, soit IDispenser:createRessource de dotNet).
 
Bref, le merdier si je puis me permettre l'expression
 
Un sacré sac de noeud, j'ai beau "GC.Collecté" dans tous les sens, impossible de m'en sortir.
 
Je commence à avoir de gros doute sur la capacité de grosse tenue en charge de programmes DOT.Net, tant les possibilité de libération de mémoire manuelles sont peu précises et peu nombreuses.
 
PS: je précise que j'ai bien vérifié que toutes mes connexions / readers B2D soient correctement fermés et détruits, et que même en supprimant la récupération d'infos en B2D et, encore plus fort, la génération effective du PDF, le problème est ralenti mais finit par apparaître !

Pour info je cumulais 2 problemes distincts sur ce coup là, d'où la difficulté d'interprétation.
 
- Un bug sur des drivers ODBC (2.81) pour informix générant une augmentation de mémoire
 
- Un bug référencé ici: http://www.dotnet247.com/247refere [...] =88&type=1