Personnellement, je pense qu'il le faut, car pour moi cela crée un nouveau pointeur qu'il faut donc nullifier. Après peut-être que ça se passe d'une autre façon car apparement c'est ce qui est resorti de la plupart des sujets là-dessus. _________________
Personnellement, je pense qu'il le faut, car pour moi cela crée un nouveau pointeur qu'il faut donc nullifier. Après peut-être que ça se passe d'une autre façon car apparement c'est ce qui est resorti de la plupart des sujets là-dessus.
Max a écrit:
Prenons un exemple de fonction :
Jass:
function IsMonster takes unit U returns boolean
return GetPlayerId( GetOwningPlayer(U) ) > 11
endfunction
Ne devrait-on pas dans l'exemple présent nullifier U ?
Il faut distinguer deux choses, le leak d'objets et le leak de variables.
Ce qui nous amène aux trois raisons suivantes, qui spécifient qu'il n'est pas nécessaire de nullifier U.
1. Aucun objet n'est créé dans cette fonction, donc il n'y a pas de leak d'objets, donc pas de suppression d'objet à faire (call Destroy/Remove...)
2. Aucun objet n'a été supprimé, donc aucune variable locale ne pointe vers un objet supprimé, donc il n'y a aucune raison de nullifier qui que ce soit.
3. Les variables locales déclarées en tant qu'arguments de fonction n'ont pas besoin d'être nullifiées car elles sont toujours détruites.
Je vous invite également à (re)lire ceci _________________
Bêta Systems:70% Bêta Spells:13% Bêta Arts & graphics:70%
3. Les variables locales déclarées en tant qu'arguments de fonction n'ont pas besoin d'être nullifiées car elles sont toujours détruites.
Donc, dans l'exemple ci-dessus, pas besoin de nullifier/détruire le groupe ? (cette fonction ne sert à rien, je suis d'accord, c'est juste un exemple)
Jass:
function GetFirstUnit takes group whichGroup returns unit
return FirstOfGroup(whichGroup)
endfunction
Citation:
2. Aucun objet n'a été supprimé, donc aucune variable locale ne pointe vers un objet supprimé, donc il n'y a aucune raison de nullifier qui que ce soit.
Mais la variable unité est un pointeur inutilisé qui ne sera pas détruit quand l'unité sera supprimée. J'avoue que ce point la n'est pas clair. Quelqu'un pourrait me l'expliquer ou me donner un tuto (en anglais ou en français )
Merci _________________
Inscrit le: 13 Jan 2009 Messages: 550 Sujets: 47 Spécialité en worldedit: La partie déclencheurs sauf le GUI.
Posté le: 19/07/09 11:59 Sujet du message:
Eme a écrit:
Tu as dis toi-même qu'il était inutile de nullifier les variables de types unités.
Huh?
profet a écrit:
2. Aucun objet n'a été supprimé, donc aucune variable locale ne pointe vers un objet supprimé, donc il n'y a aucune raison de nullifier qui que ce soit.
Ce que tu disais ici contredit cela :
profet a écrit:
Une handle (=identifiant d'une entité/objet de war3) ne peut être recyclée que si l'objet stocké (en mémoire) est détruit, et si aucun pointeurs ne pointent encore dessus. Quand vous laissez un pointeur rester en mémoire, il ne fait pas qu'utiliser ces quelques octets, il empêche aussi la handle d'être recyclée, ce qui est plus problématique.
D'après ta deuxième citation, le moment où l'on va supprimer l'unité n'a aucune importance (ça peut être deux heures après l'appel de la fonction), c'est lors de la suppression de cette unité que le handle U empêcherait tous les pointeurs vers cette unité de se détruire. Cependant le 3 suffit (même si je ne comprends pas la différence avec une variable locale).
Par contre je ne comprends pas : "Une handle (=identifiant d'une entité/objet de war3) ne peut être recyclée que si l'objet stocké (en mémoire) est détruit, et si aucun pointeurs ne pointent encore dessus."
Si on met le handle à null, "l'objet stocké" c'est quoi alors, puisque que le pointeur n'est alors plus censé pointer vers quoi que ce soit ? C'est... le dernier objet pointé avant la nullification ? _________________
Je pense qu'il y a une petite confusion entre handle et pointeur et tout ça... c'est pas évident.
Entrons un peu dans les détails:
1. Objets
J'imagine que tu as une notion de ce qu'est un "objet" dans le sens programmation du terme.
Tous les élements de warcraft3 en sont, qu'il s'agissent d'unité ou de doodads, mais aussi les textes affichés à l'écran, les sons....
Ces "objets" sont une quantité de mémoire variable allouée pour stocker les infos relatives à ce que j'appellerais des "entités" de Warcraft3.
2. Handles
Les handles ne sont pas vraiment des pointeurs comme on en rencontre en C par exemple, car ce ne sont pas des adresses mémoire à proprement parler.
Warcraft3 stocke ses "objets" dans une table, et donne à chacun un identifiant qui permet par la suite de récupérer "l'adresse mémoire" de l'objet. Il me semble d'ailleurs que dans warcraft, cela passe par deux tables consécutives..détail...
Cet identifiant est ce que l'on appelle "handle" que l'on pourrait traduire en français par "manipulateur" (to handle = manipuler).
Cette "handle" est une valeur entière, que l'on a fréquemment récupérée grâce à la fameuse fonction H2I.
Lorsqu'un objet est détruit correctement, son identifiant est "libéré" et pourra être réassigné à un nouvel objet par la suite.
3. Leaks d'objets
Certaines fonctions créent des "objets" (cf. 1), à qui sont associées des identifiants (handles, cf. 2) sans que l'utilisateur novice ne s'en doute, comme par exemple:
Jass:
constant native GetUnitLoc takes unit whichUnit returns location
//équivalent à:
function GetUnitLoc2 takes unit wichUnit returns location
return Location( GetUnitX(wichUnit), GetUnitY(wichUnit) )
endfunction
Si cet utilisateur utilise GetUnitLoc (dans un sort par exemple), sans prendre la précaution de supprimer la location créée, des locations seront alors créées à chaque lancement du sort, et ne seront plus jamais réutilisées, occupant petit a petit de la mémoire inutilement. C'est ce qu'on appelle "leak d'objet".
4. Leaks de handles Je me suis mal exprimé tout à l'heure en utilisant à tord le terme de "leak de variables", je voulais en fait signifier le fait, que ce leak est dû à l'utilisation des variables (en ne les nullifiant pas), mais il s'agit en fait d'un leak de handle.
Dans notre cas précédent, le leak d'objet entraine également l'utilisation définitive (jusqu'à la fin de la partie) de l'identifiant qui lui est alloué, qui ne pourra pas être réutilisé, il y a alors "leak de handle".
Dans le cas du "leak à cause des variables", il se produit également quelque chose d'étrange, à savoir que lorsque l'on détruit un objet et si une variable pointe encore sur cet objet, il est correctement détruit (donc pas de leak d'objet) mais sa handle n'est pas libérée (=> leak de handle), d'où la nécessité de la "nullifier".
Note: il me semble que le problème est le même pour les variable locales ou globales, à la différence prêt que la variable globale n'est jamais détruite (contrairement aux locales qui le sont en fin de fonction), donc il sera toujours possible de changer sa valeur par la suite et ainsi de libérer la handle fantôme.
Note2: il n'est pas forcément nécessaire de "nullifier" la variable, il suffit juste qu'elle ne pointe plus vers cet objet, c'est à dire vers un autre, ou vers "rien" (null).
Note3: étrangement, les arguments des fonctions (assimilés à des variables locales), ne "reference count" pas les handle, et n'empêchent donc pas la handle d'être libérée si l'objet est détruit. Ils n'ont donc pas besoin d'être nullifiés.
5. Le problème des Leaks
Il y a deux problèmes bien distincts:
- Le leak d'objets ne concerne que la configuration matérielle, car cela consomme de la RAM. Problème maintenant quasi insignifiant compte tenu de la quantité de mémoire vive disponible sur les ordinateurs actuels et les quantités infinitésimales perdues (il faudrait des parties de plusieurs heures avec des leak très fréquents pour consommer les gigas de RAM disponibles..)
- Le leak de handle, bien plus problématique... car Warcraft3 perd un peu pied lorsque l'on atteint un grand nombre de handles (je suis déjà passé lors de tests, à moins de 1fps au bout de 20 minutes de jeu.. avec des messages chat qui s'affichaient presque une minute plus tard à l'écran...etc..)
Pour en revenir à ta question, si l'on étudie ta fonction:
Jass:
function IsMonster takes unit U returns boolean
return GetPlayerId( GetOwningPlayer(U) ) > 11
endfunction
On peut remarquer qu'aucune des 2 fonctions (GetPlayerId et GetOwningPlayer) ne créé d'objets (la première retourne un entier, la deuxième retourne un "joueur" mais ne le créé pas) donc pas de leak d'objet.
Il n'y a pas non plus de fonction qui détruise un objet donc pas de risque de leak de handle non plus.
Alors OUI, ton objet (unité) occupera toujours de la place en mémoire, et utilisera un indentifiant, mais cela est totalement normal vu que l'unité est toujours présente sur la carte
Voilà! J'espère avoir été assez clair^^ _________________
Bêta Systems:70% Bêta Spells:13% Bêta Arts & graphics:70%
Inscrit le: 13 Jan 2009 Messages: 550 Sujets: 47 Spécialité en worldedit: La partie déclencheurs sauf le GUI.
Posté le: 20/07/09 17:28 Sujet du message:
Hm pas mal pas mal !
Donc si j'ai bien compris, si j'ai 15 variables de type unité pointant vers la même unité, puis que je détruis cette unité, il y aura un leak de un seul handle, celui de l'unité ? Et s'il y a leak d'objet, il y a forcément également leak de handle (celui de cet objet) ?
Pour résumer, variable de type objet = pointeur vers handle ?
Par contre une chose que je ne comprends pas : si les variables locales sont vraiment détruites en fin de fonction, elles ne devraient plus consister en un pointeur vers handle (vu qu'elles n'existent plus ?), alors pourquoi les nullifier ?
profet a écrit:
Il y a deux problèmes bien distincts:
- Le leak d'objets ne concerne que la configuration matérielle, car cela consomme de la RAM. Problème maintenant quasi insignifiant compte tenu de la quantité de mémoire vive disponible sur les ordinateurs actuels et les quantités infinitésimales perdues (il faudrait des parties de plusieurs heures avec des leak très fréquents pour consommer les gigas de RAM disponibles..)
- Le leak de handle, bien plus problématique... car Warcraft3 perd un peu pied lorsque l'on atteint un grand nombre de handles (je suis déjà passé lors de tests, à moins de 1fps au bout de 20 minutes de jeu.. avec des messages chat qui s'affichaient presque une minute plus tard à l'écran...etc..)
Je me demandais comment cela se faisait que je ramais (beaucoup de spikes) arrivé à un leak de 1 go (voire moins) alors que j'ai 3 go de mémoire vive... donc ça ne vient pas de ma ram, mais de war3 lui-même qui a un problème pour gérer tous ces handles...
Sinon je me demande, l'écran noir en fin de partie (qui peut durer de nombreuses minutes suivant la quantité de leak et les performances de l'ordinateur), dû au leak d'objets, est-ce à cause du temps que met l'ordinateur à libérer la mémoire utilisée par le leak d'objets ou celui des handles (ou les deux) ? _________________
Inscrit le: 13 Jan 2009 Messages: 550 Sujets: 47 Spécialité en worldedit: La partie déclencheurs sauf le GUI.
Posté le: 20/07/09 17:36 Sujet du message:
Autrement je me pose une question concernant la différence (ou non) concernant la façon dont war3 gère les variables globales et celle dont il gère les variables locales.
J'ai entendu parler de "pile" et de "tas", qui à mon avis est une chose que l'on peut comparer à "mémoire vive" et "mémoire morte", mais dans la mémoire vive elle-même (ou peut-être que je me trompe). L'utilisation de la pile serait donc plus rapide et moins coûteuse que celle du tas.
Donc au premier abord je me suis dit que l'utilisation de variables globales dans des fonctions utilisées très souvent est plus efficace que l'utilisation de variables locales, puisque qu'elles sont créées une seule fois, et non créées, détruites, recréées, redétruites... mais ça ce serait dans le cas où les locales et les globales soient gérées de la même façon dans la mémoire.
Inscrit le: 23 Aoû 2007 Messages: 7143 Sujets: 147 Spécialité en worldedit: le troll, le flood, la vulgarité, mon coeur balance Médailles: 2 (En savoir plus...)
Posté le: 20/07/09 18:05 Sujet du message:
Premièrement si tu es arrivé à un point où ton seul souci est de savoir si tu dois utiliser une globale ou une locale, tu n'as pas vraiment de soucis à te faire, car tu es déjà arrivé à un degré d'optimisation tel que les pouillèmes encore gagnés ne seront jamais perceptibles, cela satisfera juste ton égo et/ou ton perfectionnisme.
Dans l'hypothèse bien sûr où tu maitrises déjà des techniques permettant elles de réellement gagner en performance.
Recyclage plutôt que création/destruction d'handle (si c'est facilement faisable).
Utilisation d'un seul groupe unité pour les enum instantanés d'unités + codage dans le filter.
Codage dans des conditions plutôt que des actions.
Utilisation d'une seul dummy par joueur pour les spells triggerisés, etc.
Cela clarifié, il semblerait que pour une utilisation d'une variable locale cela n'est "plus rapide" qu'au bout de X fois d'utilisation dans la même fonction, compte tenu du temps de déclaration/destruction de la variable.
Je ne te dirais pas d'âneries je n'ai aucune idée de la valeur de "X".
Mais cela ne devrait pas dépasser la dizaine d'utilisation.
Outre le gain énorme ( ) que procure l'utilisation d'une globale par une locale c'est que l'on peut raisonnablement ne pas la nullifier à la fin de la fonction, étant donné que sa valeur sera probablement réécrit plus tard en cours de jeu. (yeah on est pas OFF-TOPIC )
C'est moins vrai pour les membres d'une struct, ou plus simplement une simple global array, car à un moment du jeu on peut avoir besoin de 100 instances de la struct puis plus tard ne jamais dépasser le 10.
Il est donc de bonne habitude de déclarer une method onDestroy qui nullifie les membres "handle" de la struct quand une instance de celle ci est détruite.
Maintenant cela rend ton code plus ugly, alors il faut se poser la question de la nécessité d'une telle chose.
Sache simplement que dans bien des cas l'utilisation d'une globale à la place d'une locale est plus "performant". _________________
Inscrit le: 13 Jan 2009 Messages: 550 Sujets: 47 Spécialité en worldedit: La partie déclencheurs sauf le GUI.
Posté le: 20/07/09 19:14 Sujet du message:
Troll-Brain a écrit:
Premièrement si tu es arrivé à un point où ton seul souci est de savoir si tu dois utiliser une globale ou une locale, tu n'as pas vraiment de soucis à te faire, car tu es déjà arrivé à un degré d'optimisation tel que les pouillèmes encore gagnés ne seront jamais perceptibles, cela satisfera juste ton égo et/ou ton perfectionnisme.
Dans l'hypothèse bien sûr où tu maitrises déjà des techniques permettant elles de réellement gagner en performance.
Troll-Brain a écrit:
Ce n'est pas que je me soucie d'un tel degré de précision, mais j'aimerais bien comprendre ...
Pour moi c'est un peu la même chose, par contre j'essaie de me soucier d'un gros degré de précision concernant mes connaissances en programmation... _________________
Inscrit le: 23 Aoû 2007 Messages: 7143 Sujets: 147 Spécialité en worldedit: le troll, le flood, la vulgarité, mon coeur balance Médailles: 2 (En savoir plus...)
Posté le: 20/07/09 19:44 Sujet du message:
Citation:
Pour moi c'est un peu la même chose, par contre j'essaie de me soucier d'un gros degré de précision concernant mes connaissances en programmation...
Bah comme tu l'as dit c'est assez intuitif que l'utilisation d'une locale vs globale est plus lent, si la variable n'est utilisé qu'une seule fois.
Par contre en effet j'ignore pourquoi cela serait plus rapide à partir de X fois.
Pour la partie savoir, tu peux poser ta question sur wc3campaigns(www.wc3.net), y'a surement Pitzermike ou PiperDream, je confonds toujours les 2 noms, qui en savent plus à ce sujet.
Concernant l'aspect purement performance c'est vérifiable avec les fonctions natives de japi et la version 1.21 de war3. _________________
Toutes les heures sont au format GMT + 1 Heure Aller à la page 1, 2Suivante
Page 1 sur 2 La question posée dans ce topic a été résolue !
Vous ne pouvez pas poster de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas voter dans les sondages de ce forum
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
Médailles
S'enregistrer
Profil
Se connecter pour vérifier ses messages privés
Connexion
Uploader une map ou une image
Max
)
)