IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Framework .NET Discussion :

Différence .net Framework / Core Utilisation mémoire


Sujet :

Framework .NET

  1. #1
    Membre régulier
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    mars 2013
    Messages
    72
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2013
    Messages : 72
    Points : 85
    Points
    85
    Par défaut Différence .net Framework / Core Utilisation mémoire
    Bonjour,

    Alors je ne fait que du codage de petits jeux mais soit il y a une grosse différence au niveau gestion mémoire soit l'analyseur de mémoire est bugué (ce qui m'étonnerai).

    Je suis sous VS2019 avec Monogame.
    Mes anciens projets de VS2017 ouvert avec VS2019 ne présentent aucun problème de mémoire.(ils utilisent tous le .Net Framework 4.5)
    Depuis peu j'introduis les animations de Spine sous VS2019 avec un projet test, et impossible de régler sur le .Net Framework, c'est directement sur le .net Core 3.1).
    Je me dis de toute façon pour moi cela ne devrait rien changer ou pas grand chose à mon niveau.

    Le projet teste mes animations, et en cliquant je switch de screen pour une autre animation.
    Sauf que finalement si, un projet test pour mes animations Spine créé sous VS2017 et lancé sur VS2019 me donne une utilisation mémoire de 102Mo et à chaque switch de screen je prend en moyenne 10Mo jusqu'à 140Mo, après je me stabilise.

    Sauf que si je crée un projet VS2019 avec .Net Core 3.1 ou 5 d'ailleurs, utilisation mémoire me donne 97Mo et à chaque switch de screen je prend en moyenne 15Mo et je peux aller très loin (je me suis arrêter à 3Go).

    Si quelqu'un pouvait m'éclairer.
    Merci d'avance

    PS : lorsque je parle de l’utilisation mémoire, c'est le graph de débogage de VS, sinon dans le gestionnaire de tâches, je prend en moyenne 1Mo

  2. #2
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    avril 2007
    Messages
    13 916
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : avril 2007
    Messages : 13 916
    Points : 24 555
    Points
    24 555
    Par défaut
    déjà il ne faut pas se fier à un programme en mode debug, il consomme plus de tout (car garde des ref sur plein de choses pour pouvoir débugger facilement)
    et d'un vs à l'autre ca consomme peut etre différement

    pour faire du benchmark il faut compiler en release et lancer hors vs

    après de ce qui est connu .net core consomme moins de mémoire à vide, et surement un peu moins en utilisation (GC avec un seuil mini plus bas et différemment codé je crois)
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  3. #3
    Membre régulier
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    mars 2013
    Messages
    72
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2013
    Messages : 72
    Points : 85
    Points
    85
    Par défaut
    Merci Pol63,

    Mes tests n'ont été fait que sur VS2019, j'ai créer un projet sur VS2017 + monogame pour pouvoir lui attitrer le .Net Framework en framework cible.

    après de ce qui est connu .net core consomme moins de mémoire à vide, et surement un peu moins en utilisation (GC avec un seuil mini plus bas et différemment codé je crois)
    Oui, c'est ce que j'ai cru comprendre juste avant de venir poster. J'ai lu pas mal d'articles qui vantaient les mérites du point de vue mémoire.
    Ce qui m'a amené à me poser des questions du " pourquoi pas chez moi?" :/

    Mais je vais faire les tests en release et voir ce que cela donne.
    Si ce n'est pas concluant je créerai des projet sous VS2017 et je les ouvrirai avec VS2019 (c'est juste parce que HLSL Tools ne bug pas avec VS2019).

  4. #4
    Membre régulier
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    mars 2013
    Messages
    72
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2013
    Messages : 72
    Points : 85
    Points
    85
    Par défaut
    Après avoir recréé plusieurs projets test, release avec le .exe directement ou même après publication, il semblerai que le GC soit un tout petit plus à la ramasse pour faire les choses tout seul et qu'il est un peu plus besoin d'aide pour faire son boulot correctement.

  5. #5
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    4 051
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 4 051
    Points : 7 262
    Points
    7 262
    Billets dans le blog
    1
    Par défaut
    A mon avis, le GC n'est pas spécialement à la ramasse.
    Ton programme a-t-il des temps morts où il n'y a aucun traitement ?
    => Si oui, alors en effet, le GC devrait s'exciter et libérer de la mémoire
    => Si non, alors le GC doit préférer gaspiller de la RAM tant qu'il n'y a pas trop de pression mémoire, plutôt que de pénaliser l'exécution du programme

    Rien de particulier à ce niveau.
    Microsoft s'est vanté avec une myriade de benchmarks d'avoir pondu un .NET Core plus rapide que .NET, et plus rapide que plus rapide de tout ce qui existait avant. Cela ne me choquerait pas une demi-seconde que cela passe par un GC plus laxiste, sachant que le précédent a été conçu à l'époque où un serveur avait 256 Mo de RAM, tandis qu'aujourd'hui le moindre PC de bureautique a 8 Go ou plus de RAM... OSEF que la calculatrice Windows prenne 5 Go de RAM, du moment qu'elle a de belles animations plus fluides qu'avant.
    On ne jouit bien que de ce qu’on partage.

Discussions similaires

  1. Forcer utilisation DLL 64bits du NET Framework
    Par lartistez dans le forum Visual Studio
    Réponses: 0
    Dernier message: 22/10/2015, 14h52
  2. [SDL 2.0] Différence utilisation mémoire entre sdl et xcb
    Par kripteks dans le forum SDL
    Réponses: 9
    Dernier message: 13/10/2014, 20h41
  3. Réponses: 1
    Dernier message: 08/01/2009, 19h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo