Transmis par: Sami actif Jeudi 30 Mars 2006 à 00:12
Cette traduction de 45 pages est l'oeuvre de Frédéric De Lène Mirouze alias Amethyste. L'article original est une bible en terme d'explications sur le modèle (si complexe) du "Dispose" .NET. Vous y trouverez tout ce dont vous avez toujours rêvé sur les finaliseurs, le garbage collector, les Safe handle, etc... Une mine d'or d'informations. A imprimer et converser précieusement.
C'est un travail superbe. Juste un regret: c'est très dur à lire sur le navigateur le plus utilisé au monde (on notera l'absence de jugement de valeur pour ou contre le navigateur en question, houla, pas de polémique).
C'est vraiment du bon boulot!
Juste une petite remarque en ce qui concerne le memory pressure:
On passe à cette fonction la taille des ressources non gérées, le ramasse-miettes adaptera sa stratégie de collection pour augmenter la pression sur cet objet.
J'avais eu l'occasion de discuter de ce point avec une des équipes de cadors de Bruno.B et ils m'avaient fait remarqué à juste titre que les méthodes GC.AddMemoryPressure(long) et GC.RemoveMemoryPressure(long) ne prenant pas de référence d'objet en paramètre, la pression doit se faire sur tout le tas et non sur un objet en particulier.
L'article original est un peu ambigu aussi, quoi que? il désigne un objet et non pas cet objet: the GC will alter its collection strategy in response to the increased amount of pressure on an object
je m'étais posé la même question car autrement le fonctionnement de MemoryPressure est incompréhensible.
La remarque de Bruno.B est d'ailleurs lumineuse!
c'est vrai que les tableaux ressortent bizarrement. Je vais vérifier ce soir mais il ne me semblait pas que cela se produisait dans le document original. (tu as une suggestion Sami?).
Pour la petite histoire j'ai commencé par le rédiger avec le traitement de texte le plus utilisé au monde. C'est pas pour polémiquer, mais j'aimerai bien pouvoir créer un style simplement en chargeant des fichiers css. Cela faciliterai les finitions.
Mais bon, c'et peut être faisable, après tout vu c'est juste moi qui ne sait pas comment faire.
Chez moi (IE6/FireFox), les tableaux s'affichent très bien. Ils s'étalent et occupent toute la dimension de l'écran lors du resize et s'adaptent pour des définitions plus petites. Sans compter que lors de l'impression aucun mot n'est coupé.
En fait, j'avoue que je ne vois pas trop ce que vous reprochez à la mise en page, les couleurs ? les tailles de cellules?
Ok pigé, Matthieu a raison. C'est un pb avec les style MSO Office que tu as utilisé pour l'article. Les largeurs sont en durs et comme je l'ai fais à partir d'un écran 1200/1000, la mise en page ne m'a pas sauté aux yeux (bouhh le mauvais testeur).
Je vais corrigér dès que j'aurais deux minutes de dispo, désolé encore pour le désagrément...
C'est pas un pb sur les styles avec des largeurs en taille absolue ? width:1116px; par exemple dans les td. En passant en 1024x768, les encadrés débordent sur ie6 et firefox.
Cet article, "c'est du lourd". Il rend parfaitement compte de la complexité intrinsèque au domaine de la gestion de ressources non-mémoire mais aussi de la difficulté pour un framework (ici .net) d'exposer le bon niveau d'interaction syntaxique avec les mécanismes internes.
A une époque où nous voyons de plus en plus d'application subir des fuites (mémoire ou non) même dans un environnement managé (.net comme Java), c'est extraordinaire de disposer d'une telle référence! Nous voyons ici comment bien faire, pourquoi faire comme cela, et nous comprenons au passage que de très nombreuses (toutes) applications passent complètement à côté de ce problème épineux.
D'une certaine manière, on en vient à regretter le déterminisme du destructeur C++ standard; j'entends d'ici les gurus de ce langage penser "nous avons déjà résolu ces problèmes en C++, .net et Java ne font que subir les conséquences d'une architecture de gestion mémoire semi-automatique (basée sur un ramasse-miettes)". C'est tout à fait vrai, mais ne perdons pas de vue:
- la productivité offerte par un environnement doté d'un GC
- dans certaines situation, l'amélioration de performances obtenue grâce à un GC face à une (mauvaise) gestion manuelle de la mémoire.
Et pour nous consoler, nous pouvons toujours nous dire qu'au moins en .NET il n'y a qu'une stratégie (grosso-modo) de garbage collecting et donc une seule classe de techniques de libération des ressources non-mémoire, parfaitement exposée dans cet article. Si un jour nous (re-)codons dans certains langages fonctionnels comme SML (MLTon), nous aurons à faire face au changement dynamique de stratégie de GC (selon la pression Cpu, mémoire, la fragmentation, la fréquence de collecting) et notre manière de libérer les ressources non-gérées ne pourrait plus faire un certain nombre d'hypothèses "simplificatrices" comme en .net et Java.
En tous cas, merci mille fois pour cet article à méditer calmement et à exploiter dans nos prochaines applications!
