Salut,

j'ai quelques questions pour vous sur l'allocation memoire

1- est-il interessant en C# de verifier le retour d'un new comme en C++? genre:

2- Si c'est possible (mais je n'en ai pas l'impression donc restons dans l'hypothetique), y'a-t-il un interet a allouer une classe de maniere statique plutot que dynamique (donc au compile-time et non pas au run-time), ou de par l'utilisation de la VM ca ne changerait rien?
(la c'est juste une question theorique pour comprendre un peu comment ca fonctionne, je ne cherche pas a faire quelque chose de precis).

Merci

Non, si une allocation est impossible (parce que manque de mémoire) la VM va balancer une exception (OutOfMemoryException en .net) et (habituellement) crasher tout le thread, une variable ne peut pas être nulle après un new.
 
Note que certaines opérations envoient une InsufficientMemoryException, qui hérite d'OOME mais a un sens différent: OOME signifie que l'allocation a échoué, et indique une probable corruption du programme. IME elle est lancée suite à une vérification de place (une opération vérifie si elle a suffisament de RAM pour s'exécuter, et si non balance une IME). Elle indique clairement qu'aucune corruption n'a pu avoir lieu, il est donc possible de la catcher et de délayer l'opération problématique ou de modifier les caractéristiques de l'opération pour diminuer sa conso mémoire.

Ce n'est à ma connaissance pas possible, et j'ai du mal à voir quel intérêt ça aurait.

 
Donc est-il interessant d'entourer un new (ou un bloc de new) de try{}? ca alourdit pas mal le code, et dans mon cas actuel je ne vois pas trop quoi faire d'autre de toute facon.

bah je pensais q'une allocation par le compilateur serait plus rapide, dans le sens ou on ne la fait qu'une fois et pas a chaque fois qu'on lance le programme (mais c'est mon experience C qui parle la).
 
 
Merci!

Non, comme je l'ai indiqué quand une OOME est balancée le thread est fucké, l'application va mourir, tenter de continuer est suicidaire parce que l'état du programme est inconnu et potentiellement incohérent. Les opérations pouvant balancer une IME (qui est elle catchable) l'indiquent probablement dans la doc.

En dehors de ces opérations spécifiant une IME, il ne sert à rien de faire quoi que ce soit. Si une allocation échoue, la VM est flinguée.

Je vois pas où le compilateur pourrait allouer quoi que ce soit dans le bytecode MSIL, donc je doute encore une fois que ça soit possible. Et de toute façon, avec les GC générationnels modernes de java ou C# l'allocation est souvent plus rapide qu'en utilisant des malloc classiques, donc aucun intérêt.

Sans compter que franchement, un peu de sérieux, faut se poser les vraies questions:

• Est-ce que le programme a des contraintes de perfs dures et n'arrive pas à les remplir
• Est-ce que le programme a des problèmes de perfs

Si une de ses propositions est vraie, on utilise un profiler pour savoir où est le problème et le résoudre réellement (par un changement d'algo, de datastructure, autre), pas un gimmick comme de l'allocation statique. Si aucune de ses propositions n'est vraie, je ne vois pas l'intérêt de se mettre la rate au court-bouillon.

 
OK je vois.
 

 
C'est plus une question theorique que necessaire, j'essaie juste de comprendre comment ca fonctionne
 
 
Merci bien!

Je sais pas ce que c'est qu'une instanciation "statique".
Par contre, ce que je sais, c'est que le GC est capable de réutiliser un objet libéré précédement (c'est d'ailleurs pour ça que t'as beau détruire des objets, la mémoire occupée reste identique généralement, puisque les objets sont juste flagués comme libres). Du coup, une nouvelle allocation va recycler un objet déjà chargé, et se contenter de le remettre dans l'état où il serait s'il venait d'être créé, c'est dnc plus rapide et évite les soucis de se dire "grmpf je vais un new dans une boucle c'est lent il faut que je fasse une méthode 'init' dans ma classe pour pouvoir bosser sur une seule instance" : le gain de perfs sera de toute façon minime, voir nul