Discussion :

[Jean_guy]

Bonjour à tous,

Voilà dans le cadre professionel, je travaille avec les technos C++ (serveur) et C# (ile nterface).

Nous avons utilisé Purify, associé à Visual Studio.

En C++ les résultats permettent de vérifier le code etc.. alors qu'en C# les résultats ne sont pas concluants. Nous ne possèdons alors que des graphismes avec quelques appels au Garbage qui se trouvent être inssufisant.

J'aimerais savoir si vous connaissez une appli permettant de mieux cerner le problème de fuites possibles en C# et oui l'appel du Garbage n'est pas infaillible; une appli tourne pendant un moment correctement mais après voit le CPU de la machine être consommé de maniere exponentielle et ne revient plus au seuil minimal d'utilisation.

Merci pour votre aide, j'espère avoir été clair et compréhensif, veuillez m'excuser si cela n'est pas le cas, il se fait un peu tard.

Bonne soirée à vous et encore merci.

[anthyme]

y a pas de fuite mémoire en code managé ...

a la rigueur si tu utilise des objets IDisposable sans les disposer quand il ne sont plus utilisé il reste pas mal de chose ouverte qui peuvent utiliser des ressources

[dev01]

y a pas de fuite mémoire en code managé ...

en code managé oui mais en .NET non

a la rigueur si tu utilise des objets IDisposable sans les disposer quand il ne sont plus utilisé il reste pas mal de chose ouverte qui peuvent utiliser des ressources

exactement, 99,9% des problèmes de mémoire viennent des ressources non managé qui ne sont pas "dispose" après utilisation

[anthyme]

ma réponse en elle même est un paradoxe

[SirJulio]

Salut,

les disposables peuvent poser un probleme d'allongement annormal de la durée de vie mais de la à parler de "fuite" stricto sensu, c'est un peu excessif. Par contre, ce probleme peut en effet devenir dramatique si l'application créé des objets de ce type à foison.

Pour note, les fuites peuvent exister en .Net du genre le coup classique de l'event ou de la list<> static qui gonfle sans fin. Ca reste marginal, mais ca arrive. =)

Bref, je ne connais pas trop les outils commerciaux pouvant exister (ne les utilisant pas), mais CLR profiler permet d'avoir une bonne idée de qui fait quoi (tu laisses tourner ton app profiling desactivé le temps qu'elle s'affole, puis tu lances le profiling, et tu vas voir qui est le coupable dans ta timeline, ainsi que l'initiateur avec "Show who allocated").

[Jean_guy]

Merci,

En réalité le problème n'est pas réellement compliqué , l'appli est de plus en plus gourmande sur la durée. Donc appel du Garbage insuffisants.
On a stratégiquement forcé certains appels mais cela n'a pas solutionné notre problème.

La réelle question est existe-t-il un procédé ou un outil permettant d'identifier la source de ce manquement ou l'origine, la cause de ce gonflement.

Encore merci de participer à cette réflection.

[anthyme]

bin en lisant les réponses tu nous permettrait de ne pas nous répéter aller jte donne un indice :

Salut,

les disposables peuvent poser un probleme d'allongement annormal de la durée de vie mais de la à parler de "fuite" stricto sensu, c'est un peu excessif. Par contre, ce probleme peut en effet devenir dramatique si l'application créé des objets de ce type à foison.

Pour note, les fuites peuvent exister en .Net du genre le coup classique de l'event ou de la list<> static qui gonfle sans fin. Ca reste marginal, mais ca arrive. =)

Bref, je ne connais pas trop les outils commerciaux pouvant exister (ne les utilisant pas), mais CLR profiler permet d'avoir une bonne idée de qui fait quoi (tu laisses tourner ton app profiling desactivé le temps qu'elle s'affole, puis tu lances le profiling, et tu vas voir qui est le coupable dans ta timeline, ainsi que l'initiateur avec "Show who allocated").