Discussion :

[tankerpat]

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

[Pol63]

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)

[tankerpat]

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).

[tankerpat]

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.

[StringBuilder]

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.