CLIENT/SERVEUR ET PIECE JOINTE

Commentaire de Xya le 29/10/2004 23:23:00

Il y a je crois 2 problèmes avec l'envoi:
D'abord tu alloues pour chaque 'bloc' de 2048 octets un nouveau tableau:

while(Lecteur.Position<Lecteur.Length)
{

      byte[] tableau = new Byte[2048];
      ...
}

Je pense que tu pourrais écrire:

byte[] tableau = new Byte[2048];
while(Lecteur.Position<Lecteur.Length)
{
       ...
}

pour éviter les allocations inutiles.

Ensuite quand tu appelle ReadBytes de BinaryReader il t'alloue à chaque fois un tableau de 2048 bytes,  même problème:

while(Lecteur.Position<Lecteur.Length)
{

      byte[] tableau = new Byte[2048];
       ...
       tableau = Lire.ReadBytes(2048); //BinaryReader
       transmission.Write(tableau,0, tableau.Length);
}

En fait tu peut te passer complètement de BinaryReader:

while(Lecteur.Position<Lecteur.Length)
{
        byte[] tableau = new Byte[2048];
         ...
         Lecteur.Read( tableau, 0, tableau.Length ); //Stream
         transmission.Write(tableau,0, tableau.Length);
         ...
}

Ce qui ferait au final:

byte[] tableau = new Byte[2048];
while(Lecteur.Position<Lecteur.Length)
{
         ...
         Lecteur.Read( tableau, 0, tableau.Length ); //Stream
         transmission.Write(tableau,0, tableau.Length);
         ...
}

En ce moment je bosse aussi sur un projet qui envoie des fichiers à travers un réseau et je suis confronté au mêmes problèmes de mémoire pour les gros fichiers :)

Xya

Commentaire de Xya le 02/11/2004 15:44:00

Tu as tout à fait raison, cela ne pose pas de problème côté mémoire puisque le récupérateur de mémoire (GC) récupère la mémoire non utilisée quand il le faut, mais le GC utilise le processeur inutilement, ce qui pourrait être évité en changeant juste deux lignes de ton programme.
D'ailleurs, utiliser FileStream plutôt que BinaryReader marche tout aussi bien.


Pour montrer l'utilisation excessive du GC, j'ai utilisé CLR Profiler (http://www.microsoft.com/downloads/details.aspx?FamilyId=86CE6052-D7F4-4AEB-9B7A-94635BEEBDDA&displaylang=en)
qui enregistre entre autres les allocations et des libérations de mémoire.

Utilisation de la mémoire de ton prog non modifié (la mémoire allouée pour envoyer la pièce jointe est en rouge,  chaque libération de mémoire est marquée sur l'axe horizontal (gc #x))
http://pasaulais.free.fr/yous_client_1.png


Utilisation de la mémoire de ton prog avec les deux lignes modifiées (la mémoire allouée pour envoyer la pièce jointe est cette fois en jaune)
http://pasaulais.free.fr/yous_client_2.png


Dans le premier on a plus de 500 libérations de mémoire en  
170 secondes (à peu près trois libérations par secondes) et dans le deuxième juste 6 dans le même temps.

Tout ca pour montrer à quel point ton prog pourrait profiter de changer juste 2 lignes de son code :)


Xya

Commentaire de Xya le 02/11/2004 19:02:17

Une chose à la fois, dans le désordre

>>Et merci particulièrement pour avoir déposé ces deux captures sur ton site perso....

En fait c'est juste un espace de stockage pour moi :)

>>Mais quelles sont elles ces deux lignes de code ???
Voir premier commentaire

byte[] tableau = new Byte[2048];
while(Lecteur.Position<Lecteur.Length)
{
         ...
         Lecteur.Read( tableau, 0, tableau.Length ); //Stream
         transmission.Write(tableau,0, tableau.Length);
         ...
}

dans Form1.cs (lignes 1068-1078 à peu près)

>>Dans le deuxième cas, le fait que System.String prenne autant de ressources vient du fait que tu exploites FileStream au lieu de BinaryReader ? Tu stockes en masse dans un String ?

En fait si on regarde les allocations pour String, on voit que ca vient de String.Concat et de Int64.ToString (http://pasaulais.free.fr/yous_client_3.png) qui viennent probablement de la ligne

etat.Panels[0].Text="Envoyés: " + Lecteur.Position.ToString() + " sur " + Lecteur.Length.ToString();

(En interne C# remplace les concaténations de chaînes avec "+" par String.Concat)

Je pense qu'une des solutions les plus rapides serait de bouger l'appel à Lecteur.Length.ToString hors de la boucle (la taille du fichier ne change pas, ca ne sert à rien d'appeler plusieurs fois ToString dessus) pour gagner vite fait 1,6 Mo de mémoire allouée.

>> En tous cas, merci pour tout l'intérêt que tu portes à cette source, le temps que tu y passes et les enseignements que tu m'apportes.

En fait je travaille sur un projet qui envoie aussi des fichiers sur un réseau (mais juste des fichiers, pas de système de messages), et donc j'ai été confronté y'a vraiment pas longtemps (genre 1-2 semaines) au problème de la mémoire, ce qui m'a amené à utiliser CLRProfiler (qui peut être comme tu as pu le voir très utile et que je te conseille d'utiliser sur tes projets les plus importants, pour avoir l'oeil à ce que fait ton programme en arrière plan). Donc si les problèmes dont je me suis sorti peuvent te faire gagner du temps et améliorer la qualité de ton prog, autant que tu en profites :)

Commentaire de Xya le 02/11/2004 19:32:19

>> Comme quoi, il est important de coder propre !!

En fait, je crois que le plus important avec .NET c'est que ca peut vraiment t'aider à faire des trucs sympa mais que si tu ne sais pas ce que .NET fait pour toi,  ca te peut te prendre par suprise (par exemple ici sur les 1000+ lignes de ton prog, moins de 10 posaient problème pour ses performances, mais changer ce petit nombre de lignes a radicalement changé ses perfs)

>>Merci encore pour ton aide !!

De rien :)