11524 sujets

JavaScript, DOM et API Web HTML5

Pages :
(reprise du message précédent)

CNeo a écrit :
En PHP il me semble que les regexp sont plutôt lentes mais j'avoue que pour le Javascript je ne sais pas.

Moi non plus, c'est à tester.
CNeo a écrit :
Tu sais ce qu'on dit : "1ms+1ms+1ms..." et aussi le fameux "il n'y a pas de petits gestes quand on est 60 millions à les faire" qui s'applique bien en informatique aussi.

Je sais surtout que :
Donald Knuth a écrit :
L'optimisation prématurée est la source de tous les maux.

(voir sur Wikipédia)
et je pense que c'est bien plus important pour être un bon programmeur. Smiley smile
CNeo a écrit :
Je pense que nos deux objets répondent à deux demandes différentes donc soit on met les deux soit on ne met que la tienne c'est à toi de décider en sachant que de toute façon il restera ce sujet comme trace et qu'il peut-être mis en lien.

Je suis bien d'accord. Par contre, pourquoi n'émets-tu pas l'hypothèse de ne mettre que le tien ? Pour ma part, je pense que l'on peut mettre les deux.
Julien Royer a écrit :
Je suis bien d'accord. Par contre, pourquoi n'émets-tu pas l'hypothèse de ne mettre que le tien ? Pour ma part, je pense que l'on peut mettre les deux.
Parce que c'est le tien qui marche dans tous les cas.

Édit : on met les deux dans le même message pour plus de clarté ?
Modifié par CNeo (31 Jul 2007 - 13:04)
CNeo a écrit :
Édit : on met les deux dans le même message pour plus de clarté ?

Ca me va. Tu t'en charges ? Smiley smile

<edit>En fait, mon code ne marche pas sous IE. Smiley confused
J'étudie le problème.

Modifié par Julien Royer (31 Jul 2007 - 15:11)
Julien Royer a écrit :
Ca me va. Tu t'en charges ? Smiley smile
D'accord. Je rédige et si tu vois des corrections à faire n'hésite pas.

Édit : OK, j'attends que tu corriges avant de rédiger donc.
Modifié par CNeo (31 Jul 2007 - 15:12)
CNeo a écrit :
Édit : OK, j'attends que tu corriges avant de rédiger donc.

C'est OK, j'ai supprimé getAll pour l'instant, il faudra que je me penche dessus.
Je me suis amusé à faire un test de performances entre la méthode avec les expressions régulières et la méthode de PPK.

Je vous laisse essayer, mais j'ai observé les résultats suivants :
- Sous FF 2, les expressions régulières sont légèrement plus lentes.
- Sous IE 7, les expressions régulières sont trois fois plus rapides.
- Sous Opera 9, les expressions régulières sont plus rapides (à peu près 2/3 du temps de la méthode de PPK).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"><head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<title></title>

	<script type="text/javascript"><!--

var documentCookie = "lv9=11857976055; __utma=883209761.10994475675.11763618115.11858768141.11858841503.2288; __utmz=883520971.11763615115.10.01.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); lv1=11842155963; lv14=118354608735; lv23=115841400371; lv18=118494416820; lvt=2758141; lv6=118495156845; lv21=151851275026; lv25=110848454938; lv5=118754884413; lv=118855884453; lv24=11835458728; lv20=11852635857; lv4=11838548726; lv17=11832548733; lv10=11851803637; lv0=11749904439; lv2=11283548724; lv26=11846623638; lv3=11832548725; __utmc=883240971; __utmb=188320971";

function getCookieRegExp(name) {
  var o = new RegExp(name + "=([^;]+)").exec(documentCookie);
  return o && unescape(o[1]);
}

function getCookieSplit(name) {
  var nameEQ = name + "=", ca = documentCookie.split(';');

  for (var i = 0; i < ca.length; i++) {
    var c = ca[ i];
    while (c.charAt(0) == ' ') c = c.substring(1, c.length);
    if (c.indexOf(nameEQ) == 0) return unescape(c.substring(nameEQ.length, c.length));
  }

  return null;
}

function curTime() {
  return new Date().getTime();
}

window.onload = function() {
  var IT_NB = 10000, COOKIE_NAME = "lv1";

  var regExpTime = curTime()

  for (var i = 0; i < IT_NB; ++i) {
    getCookieRegExp(COOKIE_NAME);
  }

  regExpTime = curTime() - regExpTime;

  var splitTime = curTime();

  for (var i = 0; i < IT_NB; ++i) {
    getCookieSplit(COOKIE_NAME);
  }

  splitTime = curTime() - splitTime;

  document.body.innerHTML = "<dl><dt>RegExp<\/dt><dd>" + regExpTime + "<\/dd><dt>Split<\/dt><dd>" + splitTime + "<\/dd><\/dl>";
};

	--></script>

</head><body></body></html>

Modifié par Julien Royer (31 Jul 2007 - 15:50)
Dans ce cas je devrais remplacer le split par la regexp dans mon script.

Édit : ah oui mais non vu que ça ne sert pas à la même chose. Smiley lol
Modifié par CNeo (31 Jul 2007 - 16:02)
a écrit :

Le fait que les regexp soient plus lentes que l'utilisation de split reste à prouver.

Vous oubliez quand même un point : split utilise lui-même des expressions régulières, même si on utilise une chaîne en tant que délimiteur (il s'agit d'une simplification syntaxique, c'est tout).
Conséquence, il est normal qu'une simple recherche soit plus rapide qu'un découpage, parce que le découpage comprend une partie de recherche.
QuentinC a écrit :
Vous oubliez quand même un point : split utilise lui-même des expressions régulières, même si on utilise une chaîne en tant que délimiteur (il s'agit d'une simplification syntaxique, c'est tout).

Ca c'est la théorie, mais rien n'empêche le moteur JavaScript de faire des optimisations et donc de ne pas passer par une expression régulière dans ce cas.
Mon objet ne semble pas fonctionner sous IE 6 chez moi est-ce que quelqu'un peut confirmer ou infirmer cela ?
Il se passe quoi si dans

get: function(name) {

    var o = new RegExp(name + "=([^;]+)").exec(document.cookie);

    return o && unescape(o[1]);

  },


document.cookie est vide ou name n'est pas défini ?
Modifié par Grumelo (17 Aug 2007 - 17:02)
Grumelo a écrit :
Mettre un var dans une boucle provoque un warning, il s'agit d'une multi redeclaration.

Je suggère donc le code

initiate: function(){
  if(document.cookie!=''){
   var bar = document.cookie.split("; ");
   var foo = '';
   for(var j=0; j<bar.length; j++){
    foo = bar[j].split("=");
    this.tab[foo[0]]=unescape(foo[1]);
    this.number++;
   }
  }
 },


Je sais..., je pinaille. Smiley biggrin
Je ne vois pas de Warning dans la console de Firefox mais si quelqu'un confirme que c'est pas bien alors je change ... Smiley cligne
Modifié par CNeo (20 Aug 2007 - 16:07)
a écrit :
Il se passe quoi si dans [...] document.cookie est vide ou name n'est pas défini ?

Sauf erreur, exec renvoie null s'il n'arrive pas à matcher. Il faudrait donc vérifier si o == null et dans ce cas renvoyer une chaîne vide ou null selon vos préférences.
En principe document.cookie est toujours défini même s'il n'y a aucun cookie d'enregistré. Ca vaut sûrement une chaîne vide et c'est tout.

Par contre un truc me paraît étrange, c'est la dernière ligne :
return o && unescape(o[1]);
Depuis quand l'opérateur && peut-il être utilisé avec des tableaux et quelle est sa signification dans ce cas ?


a écrit :
Je ne vois pas de Warning dans la console de Firefox mais si quelqu'un confirme que c'est pas bien alors je change ...

En théorie définir une variable avant une boucle plutôt qu'à chaque itération fait gagner quelques nanosecondes... mais ça reste à prouver.
En tout cas, en déclarant la variable, dans la boucle, on a un avantage, pas de conflit possible puisque la variable est écrasée à la fin de chaque passage . Par contre si on la définit en dehors, il peut y avoir un risque...
Modifié par QuentinC (20 Aug 2007 - 23:18)
CNeo a écrit :
Je ne vois pas de Warning dans la console de Firefox mais si quelqu'un confirme que c'est pas bien alors je change ... Smiley cligne

Ce n'est absolument pas une erreur, mais c'est vrai que ça peut porter un peu à confusion.

En fait, l'endroit où est placé la déclaration de la variable (avec "var") au sein d'une fonction n'a aucune importance en JavaScript, ce qui n'est pas très intuitif, comme le montre l'interprétation assez logique mais erronée de Quentin.

Par exemple :
function pouet1() {
  a = 1;
}

function pouet2() {
  a = 2;

  if (false) {
    var a;
  }
}

var a = 0;
pouet1();
alert(a); // 1
pouet2();
alert(a); // 1
C'est vraiment bizarre le Javascript ... Smiley biggol
Je laisse comme c'est donc.

Édit : je pense qu'il vaudrait mieux supprimer le post de Grumelo dans le topic des scripts utiles pour le laisser "propre".
Modifié par CNeo (21 Aug 2007 - 10:00)
a écrit :

comme le montre l'interprétation assez logique mais erronée de Quentin.

Peux-tu m'expliquer plus en détail ? je n'ai pas compris du tout mon erreur si vraiment il y en a une.
Je tire ce genre de raisonnement des langages compilés tels C/C++ ou java, est-ce très différent pour un langage interprété ?
QuentinC a écrit :
Peux-tu m'expliquer plus en détail ? je n'ai pas compris du tout mon erreur si vraiment il y en a une.

Je crois que l'exemple que j'ai donné ci-dessus suffit à prouver qu'il y en a une. Smiley cligne
QuentinC a écrit :
Je tire ce genre de raisonnement des langages compilés tels C/C++ ou java, est-ce très différent pour un langage interprété ?

Cela n'a rien à voir avec le fait que le langage soit compilé ou interprété.

En EcmaScript, il n'existe pas de portée de bloc, mais seulement une portée de fonction. Le contenu de la portée d'une fonction est déterminé au moment de sa création, à partir de toutes les fonctions, variables et paramètres qu'elle comprend. Comme il n'est à ce moment-là pas possible de savoir où va passer le flux d'exécution du code, toutes les déclarations de variables sont ajoutées, où qu'elles se trouvent.

Voilà donc pourquoi l'on peut tout à fait écrire :
function pouet() {
  a = 2; // a est ici une variable locale
  var a;
}

Mais bon, ce n'est pas très clair... D'ailleurs, JSLint hurle quand on lui donne ce genre de code.
Pages :