Discussion :

[Promesses]

Bonjour,

Je voulais savoir s'il pouvait y avoir une différence de performance entre un
Event.observe(obj, "click", function fun()) et un simple <a id="toto" onclick="fun();"/>

Quand je parle de performance, je parle de mémoire utilisé par le navigateur.

Merci d'avance pour vos réponses.

[le_chomeur]

non pas spécialement de perte de performance , puisque l'action ne sera détecté qu'en cas de click ( dans ton cas ... )

le Event.observe , est utile lorsque tu utilises la même méthode sur X objet , si tu dois utiliser ta méthode sur un seul objet alors reste sur le onclick

[Promesses]

Erf, tu n'aimes pas le mot problème dans les titres de post
Avec mes excuses alors !

Merci pour ta réponse

[Bovino]

Si je peux me permettre d'être un peu tatillon, tout comme les css ont permis de séparer le contenu de la mise en forme, le "inobstrusive js" tend à séparer le contenu du comportement, il est donc plus dans l'air du temps d'éviter les onclick dans les balises et de leur préférer les Event.observe dans des fichiers séparés.

[tusssss]

Si je peux me permettre d'être un peu tatillon, tout comme les css ont permis de séparer le contenu de la mise en forme, le "inobstrusive js" tend à séparer le contenu du comportement, il est donc plus dans l'air du temps d'éviter les onclick dans les balises et de leur préférer les Event.observe dans des fichiers séparés.

L'ère du temps.

Pour le reste, vu l'utilisation des event.observe par rapport aux onclick, je pense que le onclick a encore de beaux jours devant lui.

[Promesses]

L'ère du temps.

Pour le reste, vu l'utilisation des event.observe par rapport aux onclick, je pense que le onclick a encore de beaux jours devant lui.

Qu'est ce que tu veux dire par la ?

[Bovino]

J'imagine qu'il veut dire, et je le suivrais bien volontiers sur cette voie, que l'objet event de javascript est tellement différencié entre les navigateurs que la seule option raisonnable est encore pour le moment de gérer les onclicks dans le script html sauf si l'utilisation de frameworks tels que prototypes peut se justifier.

En résumé, c'est presque pire que l'utilisation des css il y a 15 ans !

Ceci dit, vu le code que tu as donné, tu sembles utiliser prototype et dans ce cas, il me semble que le Event.oserve (dont tu remarqueras que tu peux le syntaxer obj.oserve('click', fonction) ) est mieux adapté.

[le_chomeur]

enfin bon moi ce que j'en dis ...
pour une appli perso être utiliser par-ci par la , le bon vieux onclick est d'actualité, si demain on tape sur une appli pro qui va toucher des milliers d'utilisateur on pourra commencer a regarder l'optimisation et "l'ère du temps" ...

Juste également quand vous dites que les events sont utiliser de différente manière selon les navigateurs, sans faire mon rabat joie ni autre un script compatible FF + IE couvre 95% des utilisateurs ( voir plus ... ) donc les chiffres parlent d'eux même

[Promesses]

Juste une chose encore:
Sur un objet de ma page sur lequel je mets un Event.observe, est ce que le fait de ne pas arréter l'observation quand l'objet n'est plus sur la page peut altérer les performances?

Je parle d'un cas surtout quand j'ai beaucoup d'éléments que j'observe sur une page.

[le_chomeur]

non plus , si l'objet n'existe pas , aucun évènement ne lui sera attaché a tester :

-> créer un event observe sur un objet inexistant
-> créer ton objet via le dom
-> test l'évènement

on attend ton retour

[Promesses]

ok compris

Donc pour finir le Event.observe n'alourdit pas la charge mémoire du navigateur. Ok.

Alors toute derniere question: Pourquoi si je laisse Netvibes ouvert un temps conséquent dans mon navigateur, la charge mémoire augmente, augmente et augmente ?

[le_chomeur]

il y a t-il des éléments flash sous netvibes ?
ton navigateur est-il firefox ?

si la réponse est oui aux deux question ça répond tout seul a la question => normal problème de fuite mémoire sous firefox avec les éléments flash ( voire balise object )

[Promesses]

Oh bah non.
Tu ne connais pas Netvibes ?
Aggrégateur de flux RSS.
Site quasi tout javascript

[le_chomeur]

si je connais netvibes , c'est un service de page de démarrage
mais dans les news/modules que tu affiches il y avait peut-être du flash...

sinon le fait qu'il charge les news régulièrement , il les montent peut-être en mémoire ...

[Promesses]

http://javascript.crockford.com/memory/leak.html

Alors oui, attacher des évènements prend de la mémoire sur Internet Explorer !

[Promesses]

est ce que le_chomeur peut répondre ?

[le_chomeur]

oui me voila ^^

alors je vais faire une synthèse de ce que j'ai pu apprendre suite a ce sujet et mes recherches :

Les fuites mémoire , apparaissait sous IE6 et windows xp lors de l'utilisation circulaire sur un objet exemple , je créer un objet , à l'intérieur duquel j'assigne une méthode a un objet ( cela ressemble a ton cas en plus ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
function assignerSouris(monElement)
{
monElement.attachEvent( "onmouseover", voirSouris);
 
	function voirSouris() 
	{
		//Le code ici
	}
}

les préconisations sont de passer par un évènement extérieur a l'objet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
function assignerSouris(monElement)
{
    monElement.attachEvent( "onmouseover", voirSouris);
}
function voirSouris() 
{
//Le code ici
}

Autre préconisation : relâcher les évènements lorsqu'il ne sont plus nécessaires ( les onmouseover etc une fois effectuer , et les réaffecter au commencement de l'action. ) ce qui peut paraitre logique puisqu'un mouseout n'interviendra qu'après un mouseover , donc si vous devez gérer les deux évènement , attacher le second à l'exécution du premier.

d'autre cas plus spécifique , concernant le DOM , qui selon moi sont a éviter en toute logique !

exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
//On récupère un élément présent dans la page :
var unDiv = document.getElementById('unDiv');
 
//Admetons que monObjet, est un objet js avec ses méthode et ses propriétés
monObjet.unDivPrive = unDiv; 
//Puis pour x raison on doit affecter l'objet précédemment créer a un objet de type DOM
unDiv.unObjet = monObjet;

Nous avons un appel circulaire qui causera une fuite mémoire /!\

en dehors de mes recherches , j'ai pus constater qu'en général les problèmes de mémoire apparaissait beaucoup plus souvent sur firefox qui gérait mal son garbage collector a la fermetuire d'une page ( notament celles contenant beaucoup de FLASH ) , je n'ai jamais eu de problème particulier sous ie6 ou 7 concernant des montés en mémoire ( attention a ne pas confondre avec le taux d'utilisation du processeur !! )

voici un utilitaire sous firefox , permettant de détecter ces fameuses fuite mémoire due , comme vous l'aurez compris à une bonne pratique de programmation , et également a une gestion de la mémoire pas toujours optimisé sous certain navigateur

https://addons.mozilla.org/fr/firefox/addon/2490

Allez hop au boulot

[DoubleU]

non plus , si l'objet n'existe pas , aucun évènement ne lui sera attaché a tester :

Sous ie tout du moins, tant que l'evenement n'est pas détaché et même si l'objet a été détruit, il reste en mémoire, et ce même si tu changes de page, ce qui peut provoquer de grosses fuites de mémoire si tu as beaucoup d'evènements.

Pour ma part, j'utilise tant que possible les evenements onXXX, et les gestionnaire DOM-2 seulement quand je ne peux pas faire autrement. L'avantage du onXXX, c'est que pour détacher un évenement, t'as juste à le mettre à null (ex : madiv.onclick = null), donc c'est extrêmement simple.
Pour détacher un evenement DOM-2, il te faut passer la même référence de la fonction qui a servi a créer ton listener, et ca, c'est pas toujours évident, d'où de plus gros risques de memory leak...

Edit: je viens de regarder avec IE, sous Netvibes j'ai pas vu de memory leaks, mais me semble que je l'avais déja fait ya quelques mois, j'en avais vu quelques unes, donc ils ont du corriger le tir.
Par contre, pour gmail, j'en trouve 126...

[Promesses]

Merci pour toutes ces réponses !

[le_chomeur]

DoubleU , de plus sous ie7 elles ont étés corrigés