Commentaires sur : Portée des variables Javascript

Par : Javascript Part.1 : Bonne pratiques | Maxlab | Le Blog

Javascript Part.1 : Bonne pratiques | Maxlab | Le Blog — Thu, 10 May 2012 10:25:40 +0000

[…] avec des variables globales dont l’utilisation doit être la plus limité le plus possible ( question de performance et de maintenabilité du code […]

Par : Améliorer le code javascript — Performance web

Améliorer le code javascript — Performance web — Thu, 09 Jul 2009 10:02:04 +0000

[…] y trouverez un rappel sur l’influence de la chaîne de résolution des variables javascript avec un raccourci très significatif : local variable = fast. Le graphique à l’écran 26 est […]

Par : Éric

Éric — Sun, 18 May 2008 18:05:59 +0000

Point bonus à qui trouve pourquoi dans Firefox 3 l’accès à une variable globale est plus rapide que l’accès à des variables locales au bloc parent alors qu’il doit *forcément* chercher dans les blocs parents avant de chercher dans l’objet global.

Cette bizarrerie se retouve chez Ariel, chez Rik et chez moi, dans des proportions similaires.

La seule explication que je vois c’est que la recherche de la variable elle-même n’est pas vraiment lente. C’est ce qu’il fait après avoir trouvé la variable qui peut être un peu plus lent dans le cas local2 ou local1 que dans le cas global. La question c’est : que fait-il comme traitement ou optimisation qui pourrait être significativement plus long ?

Par exemple, sachant que remonter les contextes est couteux, il pourrait tenter d’optimiser les accès futurs et mettre une sorte de cache : soit une optimisation efficace mais qu’il ne fait que pour les variables globales, soit une tentative d’optimisation pour les autres cas mais qui ce révèle contre-performance dans notre bench.

Toutes explications bienvenues

Par : Rik

Rik — Sun, 18 May 2008 17:38:38 +0000

Pour être sûr de la portée des variables et expliciter les variables globales, j’utilise tout le temps var et j’utilise window.foo pour une variable globale.

Sinon, j’ai fait tourner le bench chez moi et Webkit est impressionnant pour le moment. Si j’ai bien compris ce qu’on m’a expliqué en anglais, une des astuces consiste à déterminer (si possible) au moment du parsing (donc en statique) si une variable locale existe. Du coup, à l’exécution, ça évite de regarder inutilement dans le contexte local. Visiblement, ça casse quelques sites et ce n’est pas encore intégré au prochain moteur JS (Squirellfish qui devrait arriver bientôt). Donc ça risque de ne pas être aussi impressionnant au final, même si ce sera compensé par l’amélioration globale du moteur.

FF3ß5
global : average : 44ms
local1 : average : 57.6ms
local2 : average : 55.8ms
local3 : average : 36.4ms

Opera 9.27
global : average : 79ms
local1 : average : 78.4ms
local2 : average : 79.2ms
local3 : average : 74.8ms

Opera 9.5
global : average : 51.4ms
local1 : average : 26.8ms
local2 : average : 35.6ms
local3 : average : 24ms

Safari 3.1
global : average : 90.8ms
local1 : average : 54.8ms
local2 : average : 44.8ms
local3 : average : 34.4ms

Webkit r33561
global : average : 17.8ms
local1 : average : 17.4ms
local2 : average : 16.4ms
local3 : average : 16ms

Par : mat

mat — Sat, 17 May 2008 18:03:49 +0000

Il y avait des posts sur le blog des développeurs d’IE sur le sujet, c’est assez intéressant, et même surprenant dans certains cas: http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx , http://blogs.msdn.com/ie/archive/2006/11/16/ie-javascript-performance-recommendations-part-2-javascript-code-inefficiencies.aspx et http://blogs.msdn.com/ie/archive/2007/01/04/ie-jscript-performance-recommendations-part-3-javascript-code-inefficiencies.aspx

Grosso modo: les variables locales, c’est encore mieux que ce qu’on croit.