Worldedit
  Worldedit
Le site sur l'éditeur de warcraft 3 !
 
  FAQFAQ   RechercherRechercher   Liste des MembresListe des Membres    Groupes d'utilisateursGroupes d'utilisateurs   medals.php?sid=2665bd86e29efeb304a145e5e5212741Médailles   S'enregistrerS'enregistrer 
 ProfilProfil   Se connecter pour vérifier ses messages privésSe connecter pour vérifier ses messages privés   ConnexionConnexion 
  FAQFAQ World Editor   UploadUploader une map ou une image    UploadAjouter sa map à l'annuaire   UploadConsulter l'annuaire

LEAK : fonctions -> nullifier paramètres
Aller à la page Précédente  1, 2
 
Poster un nouveau sujet   Répondre au sujet    Worldedit Index du Forum -> Aide sur les déclencheurs
Voir le sujet précédent :: Voir le sujet suivant  
Auteur Message
 profet
Instanton Gravitationnel Singulier


Inscrit le: 21 Aoû 2007
Messages: 1633
Sujets: 53
Spécialité en worldedit: Pain d'épice multitâche (terrain, scripts, textures, modèles...)
Médailles: 2 (En savoir plus...)
Rédacteur de tuto #3 (Quantité : 1) Profet (Quantité : 1)

MessagePosté le: 21/07/09 01:36    Sujet du message: Citer

Max a écrit:
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é ?

Oui

Max a écrit:
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 ?
Oui, et oui Smile

Max a écrit:
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 ?

A cause du "comptage de référence" (reference counting), c'est à dire qu'associé à chaque handle, il y a un petit compteur, qui est incrémenté lorsqu'une variable pointe vers celle-ci, et décrémenté lorsque le lien est rompu.
Hors, il y a un bug dans la machine virtuelle du jass, qui fait que ce compteur n'est pas décrémenté lorsqu'une variable locale est détruite à la fin de l'exécution d'une fonction alors que l'objet n'existe plus, il faut donc le faire à la main en changeant la valeur de cette variable manuellement.
Ce compteur sert à déterminer si l'handle est toujours utilisée, et peut etre recyclée ou non.

Max a écrit:
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) ?

L'écran noir dure le temps que l'intégralité de la mémoire allouée à l'exécution de la carte soit libérée, cela concerne donc tous les types de leak car ils "consomment" tous deux de la mémoire vive, mais le problème du leak d'handle n'est pas d'ordre mémoire (car il n'en consomme que très peu) mais majoritairement fonctionnel (mauvaise gestion du grand nombre de handle par le moteur).
En plus des leak, il y a énormément de choses qui consomment de la mémoire dans une carte : modèles, textures, terrain, l'ensemble des objets créés (textes, sons, unités, mises a jours, sorts...).


Max a écrit:
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.
Ce n'est pas vraiment ça.
Il existe plusieurs type d'allocation de mémoire, l'allocation statique, sur la pile et sur le tas.

L'allocation statique est celle qui est fixe sur l'ensemble de l'execution du programme, à l'échelle de notre carte, ce serait tous les objets créés au chargement de celle-ci, qui le resteront jusqu'à sa fermeture (par exemple nos variables Globales)
Avantage: pas d'allocation dynamique, la quantité de mémoire utilisée ne varie pas
Inconvénient: pas de flexibilité, impossible de l'utiliser quand la quantité d'information à stocker n'est pas définie.

L'allocation sur la pile est typiquement celle des variables locales.
Avantage: la mémoire n'est consommée uniquement lorsque l'on en a besoin
Inconvénient: ce type d'allocation est la plus "coûteuse" en terme d'instructions car elle est allouée/desallouée automatiquement selon leur portée.

L'allocation sur le tas est le mode "custom" de l'allocation de mémoire (par exemple, le malloc/free en C et new/delete en C++), le programmeur est totalement libre d'allouer la mémoire comme il le veut, il est néanmoins responsable de la libérer sous peine de leak.
C'est ce que l'on fait lorsque l'on créé un objet dans warcraft3 (unité, doodads, texte...)


Citation:
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.

Si l'on suit ce que j'ai dit plus haut, lorsque l'on exécute une fonction très souvent (avec un timer court par exemple), utiliser un grand nombre de variables locales va entrainer une importante allocation/libération de mémoire ce qui entrainera une baisse des performances.
On peut donc utiliser une variables globale (dont l'allocation statique a été faite au chargement de la carte), afin d'éviter ce problème. Mais il faut bien entendu être sûr qu'il n'y aura pas de collision entre les données stockées dans ces variables globales (en cas d'utilisation de wait par exemple)

Citation:
Utilisation d'une seul dummy par joueur pour les spells triggerisés, etc.

Je ne recommanderai pas cette optimisation, car si le sort est lancé quasiment en même temps par deux unités, le dummy pourra ne pas avoir le temps d'achever le premier sort, et lancera le second à la place.

Citation:
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.

Je ne pense pas que l'accès à une variable globale soit plus lente que celui à une locale, et seule la nécessité d'allouer la seconde doit les différencier.
Cela dépend bien évidemment de la manière dont la VM gère la chose, mais le contraire serait fort étonnant.. Question
_________________

Bêta Systems: 70%
Bêta Spells: 13%
Bêta Arts & graphics: 70%
Revenir en haut
Voir le profil de l'utilisateur Envoyer un message privé Visiter le site web du posteur
 Max
Floodeur prématuré


Inscrit le: 13 Jan 2009
Messages: 550
Sujets: 47
Spécialité en worldedit: La partie déclencheurs sauf le GUI.


MessagePosté le: 21/07/09 16:29    Sujet du message: Citer

profet a écrit:
A cause du "comptage de référence" (reference counting), c'est à dire qu'associé à chaque handle, il y a un petit compteur, qui est incrémenté lorsqu'une variable pointe vers celle-ci, et décrémenté lorsque le lien est rompu.
Hors, il y a un bug dans la machine virtuelle du jass, qui fait que ce compteur n'est pas décrémenté lorsqu'une variable locale est détruite à la fin de l'exécution d'une fonction alors que l'objet n'existe plus, il faut donc le faire à la main en changeant la valeur de cette variable manuellement.
Ce compteur sert à déterminer si l'handle est toujours utilisée, et peut etre recyclée ou non.

Aaaaah enfin je comprends ça Smile

profet a écrit:
L'écran noir dure le temps que l'intégralité de la mémoire allouée à l'exécution de la carte soit libérée, cela concerne donc tous les types de leak car ils "consomment" tous deux de la mémoire vive, mais le problème du leak d'handle n'est pas d'ordre mémoire (car il n'en consomme que très peu) mais majoritairement fonctionnel (mauvaise gestion du grand nombre de handle par le moteur).
En plus des leak, il y a énormément de choses qui consomment de la mémoire dans une carte : modèles, textures, terrain, l'ensemble des objets créés (textes, sons, unités, mises a jours, sorts...).

Je croyais que l'écran noir ne venait pas de la quantité de mémoire utilisée, mais uniquement de celle utilisée par le leak (comme si l'ordinateur avait plus de mal à trouver les objets perdus Laughing).
J'ai fait deux déclo différents pour vérifier ça. Un qui crée en 12 secondes 600k points qui leak. L'autre qui crée 600k points dont chacun est stocké dans une variable différente.
Jass:
//ajout 600k points leak

//exécuté 120 000 fois pour 600 000 points
globals
    integer pointsTest_int = 0
endglobals

function Trig_ajout_points_Actions takes nothing returns nothing
    local location array points
    local integer i = 0
    loop
        exitwhen (i >= 5)
            set points[i] = Location(0., 0.)
        set i = i + 1
    endloop
    set pointsTest_int = pointsTest_int + 1
    if (pointsTest_int >= 120000) then
        call DisplayTextToForce(GetPlayersAll(), "création 600k points finie")
        call DisableTrigger(GetTriggeringTrigger())
    endif
endfunction

//===========================================================================
function InitTrig_ajout_600k_points_leak takes nothing returns nothing
    set gg_trg_ajout_600k_points_leak = CreateTrigger(  )
    call TriggerRegisterTimerEvent( gg_trg_ajout_600k_points_leak, 0.0001, true )
    call TriggerAddAction( gg_trg_ajout_600k_points_leak, function Trig_ajout_points_Actions )
endfunction
Jass:
//ajout 600k points globales

globals
    location array points_01
    location array points_02
    //.............................
    location array points_29
    location array points_30
   
    integer pointsTest_Id = 0
endglobals


function Trig_ajout_600k_points_globales_Actions takes nothing returns nothing
    local integer i = 0
    loop
        exitwhen (i >= 2)
            set points_01[pointsTest_Id] = Location(0., 0.)
            set points_02[pointsTest_Id] = Location(0., 0.)
            //.............................
            set points_29[pointsTest_Id] = Location(0., 0.)
            set points_30[pointsTest_Id] = Location(0., 0.)
            set pointsTest_Id = pointsTest_Id + 1
        set i = i + 1
    endloop
    if (pointsTest_Id >= 20000) then
        call DisplayTextToForce(GetPlayersAll(), "création 600k points finie")
        call DisableTrigger(GetTriggeringTrigger())
    endif   
endfunction

//===========================================================================
function InitTrig_ajout_600k_points_globales takes nothing returns nothing
    set gg_trg_ajout_600k_points_globales = CreateTrigger(  )
    call TriggerAddAction( gg_trg_ajout_600k_points_globales, function Trig_ajout_600k_points_globales_Actions )
    call TriggerRegisterTimerEvent( gg_trg_ajout_600k_points_globales, 0.001, true )
endfunction


La mémoire utilisée par war3.exe après la création des points est de 308 mo environ avec le déclo qui leak, et de 310 mo environ avec les variables globales (la différence doit être due aux variables globales).

J'ai un peu plus de 2 secondes d'écran noir dans les deux cas !



Merci profet pour ces réponses très claires et précises ! Rolling Eyes
(les explications sur les différents types d'allocation me seront bien utiles également Smile )
_________________
Maximaxou@northrend

Projet Max Escape Creation (éditeur d'escapes : mazes/slides) : http://max.slid.free.fr/maxEscapeCreation/
Revenir en haut
Voir le profil de l'utilisateur Envoyer un message privé
 Troll-Brain
Ri1kamoua


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...)
Grand mage créateur de sort (Quantité : 1) Rédacteur de tuto #3 (Quantité : 1)

MessagePosté le: 21/07/09 18:47    Sujet du message: Citer

profet a écrit:
Je ne recommanderai pas cette optimisation, car si le sort est lancé quasiment en même temps par deux unités, le dummy pourra ne pas avoir le temps d'achever le premier sort, et lancera le second à la place.

Non on peut rendre n'importe quel spell instantané si l'on configure correctement dans l'éditeur d'objet la dummy et le spell.

profet a écrit:
Je ne pense pas que l'accès à une variable globale soit plus lente que celui à une locale, et seule la nécessité d'allouer la seconde doit les différencier.
Cela dépend bien évidemment de la manière dont la VM gère la chose, mais le contraire serait fort étonnant..

Ca doit pouvoir se vérifier avec les custom natives de japi , comme je l'ai dit.
Je ne fait que répéter ce que des geeks soucieux de tels tests tel que "ToadCop" ont déjà affirmés, et je leur fait entièrement confiance là dessus.

Même genre d'optimisation à la con :
Si on utilise le même index d'une variable array 3 fois ou plus dans la même fonction (ou ofc un membre d'une struct ce qui est basiquement exactement une array) il est "plus performant" d'utiliser une variable globale tampon.
_________________
Revenir en haut
Voir le profil de l'utilisateur Envoyer un message privé
 profet
Instanton Gravitationnel Singulier


Inscrit le: 21 Aoû 2007
Messages: 1633
Sujets: 53
Spécialité en worldedit: Pain d'épice multitâche (terrain, scripts, textures, modèles...)
Médailles: 2 (En savoir plus...)
Rédacteur de tuto #3 (Quantité : 1) Profet (Quantité : 1)

MessagePosté le: 23/12/09 23:41    Sujet du message: Citer

/Résurrection de topic

Troll-Brain a écrit:
Non on peut rendre n'importe quel spell instantané si l'on configure correctement dans l'éditeur d'objet la dummy et le spell.

Il n'y a rien d'instantané dans un moteur graphique Wink


PS: voila et comme ça, cela fera remonter le topic pour les soucieux des "leak de handle" :p
_________________

Bêta Systems: 70%
Bêta Spells: 13%
Bêta Arts & graphics: 70%
Revenir en haut
Voir le profil de l'utilisateur Envoyer un message privé Visiter le site web du posteur
 Troll-Brain
Ri1kamoua


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...)
Grand mage créateur de sort (Quantité : 1) Rédacteur de tuto #3 (Quantité : 1)

MessagePosté le: 24/12/09 09:25    Sujet du message: Citer

Oh, vraiment ? Rolling Eyes

Par "instantané" je veux dire que tu peux ordonner avec succès à l'unité de lancer le spell X fois, sans aucun wait entre chaque ordre.
Il faut pour cela éditer des champs dans l'éditeur d'objet pour le spell et la dummy.
_________________
Le violet, c'est moche.
Revenir en haut
Voir le profil de l'utilisateur Envoyer un message privé
Montrer les messages depuis:   
Poster un nouveau sujet   Répondre au sujet    Worldedit Index du Forum -> Aide sur les déclencheurs Toutes les heures sont au format GMT + 1 Heure
Aller à la page Précédente  1, 2
Page 2 sur 2
La question posée dans ce topic a été résolue !

 
Sauter vers:  
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


Powered by phpBB © 2001, 2005 phpBB Group
Traduction par : phpBB-fr.com