Questions sur l'allocation memoire

Questions sur l'allocation memoire - C#/.NET managed - Programmation

Marsh Posté le 11-09-2008 à 22:06:40    

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:

Code :
  1. MaClasse a = new MaClasse();
  2. if(null == a)
  3.    throw new Exception("No memory" );
  4. (ou tout autre gestion du probleme)
 

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

Message cité 1 fois
Message édité par gee le 11-09-2008 à 22:07:24

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
Reply

Marsh Posté le 11-09-2008 à 22:06:40   

Reply

Marsh Posté le 11-09-2008 à 22:12:31    

gee a écrit :

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:

Code :
  1. MaClasse a = new MaClasse();
  2. if(null == a)
  3.    throw new Exception("No memory" );
  4. (ou tout autre gestion du probleme)



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.

gee a écrit :

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?


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

Message cité 1 fois
Message édité par masklinn le 11-09-2008 à 22:16:03

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-09-2008 à 22:18:27    

masklinn a écrit :


Non, si une allocation est impossible (parce que manque de mémoire) la VM va balancer une exception (OutOfMemoryException en .net, ou InsufficientMemoryException  qui hérite d'OOME) et (habituellement) crasher tout le thread, une variable ne peut pas être nulle après un new.


 
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.

masklinn a écrit :


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


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!


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
Reply

Marsh Posté le 11-09-2008 à 22:28:57    

gee a écrit :

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.


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.

gee a écrit :

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!


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.

Message cité 1 fois
Message édité par masklinn le 11-09-2008 à 22:30:59

---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 11-09-2008 à 22:48:27    

masklinn a écrit :


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.


 
OK je vois.
 

masklinn a écrit :


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.


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


---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"
Reply

Marsh Posté le 14-09-2008 à 12:24:17    

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


Message édité par MagicBuzz le 14-09-2008 à 12:24:51
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed