Jquery rapide au développement mais pas à l'exécution ?

Bonjour,

je viens de tester jquery. Je le trouve très très bien conçu. Les sélecteurs facilitent considérablement la manipulation du DOM.
J'ai cependant été déçu par les performances à l'exécution. Voici par exemple une page que j'ai faite. Cette page présente une liste de produits classés dans une hiérarchie. J'ai fais un cadre de recherche pour filtrer ces produits. Tapez un peu de texte dans la textbox, par exemple le mot "pomme" et observez la rapidité du filtrage. Si vous avez, une largeur d'écran suffisante vous pouvez aussi voir la hiérarchie de gauche qui se filtre en même temps. Le seul problème est qu'il m'a fallu une centaine de lignes de script pour en arriver à ce résultat...
Quand j'ai découvert jquery, j'ai eu immédiatement envie de refaire ce script pour voir en combien de lignes il tiendra. Seulement voilà, j'ai vite été arrêté par les performances... Sans masquer les catégories vides, et sans filtrer la hiérarchie de gauche, voici ce que cela à donné . (attention, le script est lent et bloque le navigateur pendant quelques secondes à chaque lettre tapée dans le cadre de recherche. N'interrompez pas le script, il ne vous bloquera pas longtemps).

Voici, les 2 seules lignes de jquery que j'ai écris :

    $(".Name").parents("tr").hide(); //masquer toutes les lignes
    $(".Name:contains('"+tbxValue+"')").parents("tr").show(); //puis afficher les lignes dont la colonne "Name" contient le texte tapé dans la textbox.

J'ai donc l'impression que jquery n'est pas fait pour de tels scripts gourmands en ressources (à moins que ma façon de l'écrire ne soit pas bonne ? )... dommage. Qu'en pensez-vous ?
Modifié par mathmax (07 Jun 2007 - 04:21)

Bonjour,

Je ne parviens pas à accéder à tes pages, donc je ne peux pas tester.
Mais effectivement, ton code JQuery n'est pas particulièrement optimisé. Il va parcourir (au moins) 2 fois tous les éléments de la page, vérifier qu'ils ont une classe ".Name" et éventuellement qu'ils contiennent les caractères tapés, et ce à chaque caractère entré dans le champ de texte. Pour peu que ta page soit un peu complexe, il y a de quoi être lent.

Salut,

Oui Lanza a souligné un point important. Pour la suite tu peux optimiser le code (oui deux lignes aussi ça s'optimise ) :

- Utilisation d'un nombre minimum de caractère pour lancer la recherche
- Utilisation d'un flag pour ne faire qu'une recherche à la fois
- ou Utilisation d'un bouton "filtrer"
- Utilisation des callbacks (permet de ne faire qu'une ligne)

++

a écrit :
Je ne parviens pas à accéder à tes pages, donc je ne peux pas tester.

Bizarre, j'y accède très bien de mon côté. Peux-tu réessayer et me dire si ça marche ? Es-tu le seul à ne pas pouvoir y accéder ?

a écrit :
Il va parcourir (au moins) 2 fois tous les éléments de la page, vérifier qu'ils ont une classe ".Name" et éventuellement qu'ils contiennent les caractères tapés, et ce à chaque caractère entré dans le champ de texte.

c'est vrai que je parcours 2 fois les éléments de ma page, mais la différence de vitesse entre les 2 scripts n'est pas du simple au double, mais plutôt dans un rapport de 20 !

a écrit :

- Utilisation d'un nombre minimum de caractère pour lancer la recherche
- Utilisation d'un flag pour ne faire qu'une recherche à la fois
- ou Utilisation d'un bouton "filtrer"

Ces astuces rendront limiteront le nombre d'appel au script, mais ne le rendront pas plus rapide en lui même. Je ne veux pas à tout prix utiliser jquery pour cette page, j'essaie juste de tester les différences de performance entre un script jquery et un script "normal".

a écrit :

- Utilisation des callbacks (permet de ne faire qu'une ligne)

pourrais-tu m'écrire ce que cela donnerait, je ne vois pas trop.
Modifié par mathmax (07 Jun 2007 - 15:59)

une autre question. Je trouve dommage qu'un bojet jquery ne possède pas les propriété d'un bojet DOM classique.
J'aimerais pouvoir écrire :

$("a").offsetTop = "100px"

Pour l'instant, le seul truc que j'ai trouvé est faire :

$("a")get(0).offsetTop = "100px"

Ca marche, mais je suppose que ça doit être lent car il faut aller rechercher l'objet DOM correspondant pour ensuite accéder à ses propriétés, au lieu d'y accéder directement.
N'y a t-il pas un moyen plus efficace de procéder ?

merci

J'ai réalisé un truc similaire (un filtre aussi), avec prototype.
C'est très performant
Je pense que tu peux arrêter jquery

Je ne connais pas prototype. J'ai juste vu qu'il est 3 fois plus lourd que jquery. Mais apporte t-il vraiment des chôses en plus ? (notament au niveau de la performance) ? Le parcours dans le DOM est-elle aussi aisée qu'avec jquery ?
Modifié par mathmax (09 Jun 2007 - 22:50)

Tu as raison, j'abandonne jquery pour des questions de performance... dommage, j'aimais bien. Je vais chercher un autre framework. En avez-vous d'autres à me conseiller ?

salut,

Parler d'optimisation et utiliser une bibliothèque avec tout plein de choses qui ne te servent à rien est un non sens si tu veux mon avis.

Pourquoi ne pas commencer par regarder comment optimiser ton code plutôt que de dire, c'est la faute de la bibliothèque ?

Franchement, je trouve que rien ne vaut ta propre bibliothèque, adaptée à tes besoins car tu sauras la peaufiner et la rendre pleinement utile. En maintenance, le gain est important et pour peu que tu y travailles un peu, tu n'auras rien à envier à un Prototype, Scriptaculous, jQuery, Rico, etc...
Lorsqu'arrive un problème de compatibilité par exemple (parce que oui, ça arrive des fois), tu sauras modifier ton code parce que c'est toi l'a fait. Avec une bibliothèque, tu ne feras rien, particulièrement sur Prototype dont le code est loin d'être simple.

Une bibliothèque, ça commence à être utile le jour où on s'aperçoit que le code de fonctions bien précises est plus adapté (plus performant, moins lourd) que celui qu'on a fait à la main. Sans ce minimum, ça ne sert à rien sauf à se mettre un voile sur les yeux. En dessous d'une trentaine de ko de script (ce qui n'est tout de même pas rien pour une page), ça ne sert vraiment à rien. Dans le cas inverse, il est bon de se rappeller que tout le monde ne dispose pas de haut débit lorsqu'on fait son choix.
Et enfin, te focaliser dès maintenant sur l'optimisation, c'est te tromper d'objectif ( avis personnel )

applemac a écrit :
J'ai réalisé un truc similaire (un filtre aussi), avec prototype.
C'est très performant

Dans ton contexte, oui, je n'en doute pas... Prend un vieux pc qui tourne sur linux, regarde à partir d'un navigateur autre que les plus connus, regarde à partir d'un téléphone, d'un pda, etc... Tu vas avoir quelques surprises. Je n'irais pas à dire qu'il ne faut pas l'employer mais c'est le plus souvent inutile ; il convient donc de clairement identifier tes objectifs / contraintes au préalable.

a écrit :

En dessous d'une trentaine de ko de script (ce qui n'est tout de même pas rien pour une page), ça ne sert vraiment à rien. Dans le cas inverse, il est bon de se rappeller que tout le monde ne dispose pas de haut débit lorsqu'on fait son choix.

J'ai vu qu'il y avait une compression gzip pour le javascript qui permettrait de ramener Prototype en dessous de 20 ko. Qu'en pensez-vous ? Ce genre de compression est supporté par quels navigateurs ?

a écrit :
Et enfin, te focaliser dès maintenant sur l'optimisation, c'est te tromper d'objectif ( avis personnel cligne )

pourquoi ?


Que pensez-vous de Dojo qui permettrait de ne conserver dans la librairie que les fonctionnalités dont on a besoin et avoir une librairie assez légère ?
Modifié par mathmax (11 Jun 2007 - 16:08)

koala64 a écrit :
Et enfin, te focaliser dès maintenant sur l'optimisation, c'est te tromper d'objectif ( avis personnel )

mathmax a écrit :
pourquoi ?

La première chose que je cherche dans un script est de le faire fonctionner, puis de vérifier la compatibilité sur différents navigateurs et seulement après d'optimiser si besoin est.

Par exemple, on perd un peu sur la longueur du script en indentant à chaque déclaration et en commentant à qui mieux mieux mais en phase de développement, ça s'avère souvent indispensable. Après, le script, une fois en production, peut se compresser donc pas de problème mais au préalable, c'est impensable si on souhaite se repencher dessus. La maintenance devient très difficile quelques semaines ou mois plus tard. C'est un peu le reproche que je ferais à jQuery entre autres... Raccourcir à tour de bras, c'est bien mais pour quelquechose de simple. Un script ne se servant que de cette bibliothèque et qui pèse plus de 10ko rend la lecture fastidieuse la plupart du temps. Question d'habitude en même temps...

Par ailleurs, l'un des plus gros freins est l'optimisation des boucles. Il n'est pas rare qu'on fasse des tours en trop et parfois, cela se corrige par quelques restrictions. Ce facteur là, on peut le corriger d'entrée de jeu avec un peu d'habitude mais ça me semble plus être du domaine de la touche finale plutôt qu'autre chose.

Et si tu devais comparer Prototype à jQuery ? Lequel préférerais-tu ? Trouves-tu que Prototype est plus flexible, que le code écrit avec cette bibliothèque est plus proche du javascript "normal" et donc plus performant.
Parce que le manque de performance de jquery, je l'attribut au fait qu'on écrit en quelque sorte des requêtes sur les objets DOM sans trop contrôler ce qui se passe derrière.

mathmax a écrit :
Et si tu devais comparer Prototype à jQuery ? Lequel préférerais-tu ?

Au premier abord, jQuery parce que je préfère miser sur la légèreté. Prototype est certes très complet mais le code est très difficile d'accès et je ne suis pas en mesure de le modifier comme je l'entends.

Si un client me demande de faire une modif', et dieu sait qu'il y en a de nombreuses au fur et à mesure qu'on avance, je vais passer trois plombes à savoir d'où vient le problème dès lors que ce dernier vient réellement de la bibliothèque et non de mon fait. Je ne dis pas ; ces bibliothèques sont constituées par des développeurs ayant une grande expérience mais prévoir le comportement de chaque navigateur, c'est vraiment un truc de dingue susceptible de mettre n'importe qui à la rue.

Par ailleurs, à moins de faire de grosses bourdes, le côté performance me semble vraiment annexe. Je ne cours pas après les millisecondes et je ne pense pas que mes visiteurs aient cette démarche de dire :

"ouah ! t'as vu ?!! celui-là, il a mis 50ms à s'ouvrir alors que l'autre en a mis 62 !"

Donc, lorsque je code, je te dirais ni l'une ni l'autre. Même si je n'ai jamais fait certaines choses, je sais maintenant que j'ai un niveau suffisant pour les aborder correctement... sans aide. Lorsque je dois implémenter un effet déroulant avec fondu, faut pas pousser mémé dans les orties non plus ; la bibliothèque ne me sert vraiment à rien. ok, je vais peut-être mettre une ou deux heures de plus au moment de faire le script mais quand va venir le temps des retouches, je sais où je vais parce que je contrôle la moindre portion de code. Et puis je serais même en mesure de faire quelquechose qui ne se trouve pas dans ces bibliothèques, ce qui compte pas mal aussi.

A chacun de faire son choix mais pour te donner un exemple, il m'arrive de coder des fonctions qui prennent directement en compte la navigation clavier et celle à la souris. Dans une bibliothèque, je l'ai rarement pour ne pas dire pas du tout et si je ne comprend que la surface des choses, alors oui, je risque bien de perdre en performances parce que je vais te sortir une grosse bidouille bien tortueuse pour arriver à mes fins. C'est un peu comme la différence qu'il y a entre faire son code à la main et le faire via une interface graphique à la Dreamweaver... Le résultat final est loin d'être le même dès lors qu'on sort du contexte normal.
Modifié par koala64 (11 Jun 2007 - 18:54)

Les sélecteurs sont toujours un problème (niveau performances) dans ce genre de bibliothèque.

Ici tu peux trouver un benchmark de Prototype, JQuery, Mootools, Ext et cssQuery : http://mootools.net/slickspeed/

Génial ton lien . Je vois que Prototype, n'est finalement pas plus performant que jquery au niveau des sélecteurs. Par contre il y en a 2 qui semblent intéressants : MooTools et ext.
MooTools à l'air pas mal. On peut en plus choisir les composants que l'on souhaite installer. Qu'en pensez-vous ? Est-il beaucoup utilisé ? Vous parait-il mieux fait que jquery ?
Je n'ai pas trouvé grand chose sur ext, mais c'est celui qui offre les meilleurs performances visiblement. Si vous avez des infos sur ce framework, ça m'intéresse.
Toutes les comparaisons, statistiques, tests de performances entre les différents framework javacript sont les bienvenues.

Merci pour vos conseils.

mathmax a écrit :
Génial ton lien . Je vois que Prototype, n'est finalement pas plus performant que jquery au niveau des sélecteurs. Par contre il y en a 2 qui semblent intéressants : MooTools et ext.
MooTools à l'air pas mal. On peut en plus choisir les composants que l'on souhaite installer. Qu'en pensez-vous ? Est-il beaucoup utilisé ? Vous parait-il mieux fait que jquery ?
Je n'ai pas trouvé grand chose sur ext, mais c'est celui qui offre les meilleurs performances visiblement. Si vous avez des infos sur ce framework, ça m'intéresse.
Toutes les comparaisons, statistiques, tests de performances entre les différents framework javacript sont les bienvenues.

Merci pour vos conseils.

Euh?

Sur trois pc le test donne Proto et Mootools gagnants et Jquery et CssQuery a la ramasse

En fait ça dépends du navigateur. Je n'avais testé que sous IE7.

Avec IE7, jquery est un peu plus performant que Prototype.

Avec IE6, c'est l'inverse. Prototype est un peu plus performant que jquery.

Sous FF et Opera par contre, Prototype est franchement plus performant.

J'ai testé aussi sur Netscape 7 et là Prototype remporte largement la bataille tandis que MooTools 1.2dev ne renvois pratiquement que des erreurs.

Au total, les plus performants sont MooTools 1.2dev et ext 1.1b1 mais ce dernier renvois pas mal d'erreurs. Par contre étant donné que c'est MooTools qui publie le test, on peut se demander si le test n'a pas été fait à son avantage...

cssQuery 2.02 est pratiquement toujours le plus lent;

Prototype est le plus compatible et satisfaisant au niveau performances (sauf pour IE7)

Je pense donc en effet que Prototype est un bon compromis. J'ai envie aussi de voir ce que donne MooTools (leur site est très bien fait en tout cas).

Si vous avez d'autre stats ou comparaisons de ce genre, encore une fois, je suis preneur.
Modifié par mathmax (12 Jun 2007 - 19:12)

a écrit :
étant donné que c'est MooTools qui publie le test, on peut se demander si le test n'a pas été fait à son avantage... confus

Oui c'est vrai, mais sur leur blog ils assurent qu'aucun n'est favorisé et vont même publier leur suite de test en open source, à voir donc.

Sinon en ce qui concerne les différences entre les navigateurs, il y a les différences de moteurs bien sûr mais aussi les frameworks qui utilisent des méthodes différentes suivant le navigateur (utilisation de XPath quand c'est possible par exemple).

Le probléme d'efficacité de toutes ses librairies est souvent lié a l'utilisation du getElementsByClassName, qui n'est pas de mon point de vue un bon selecteur. En effet cela utlise le getElementsByTagName(*) qui vat faire une boucle sur toute les balises du site ce qui bien souvent ne sert à rien.

De plus comme ce n'est finalement pas si compliqué de selectionner un element en javascript je ne vois pas trop l'interêt d'utiliser une bibliothéque pour selectionner des objets

perso, j'utilise uniquement la fonction :

function $(strId){
	return document.getElementById(strId);
}

et ensuite je boucle uniquement sur les élements dont j'ai besoin, par exemple pour un menu:

var itemMenu = $('hemnu').getElementsByTagName('a');
  for (i=0; i<itemMenu.length; i++) {

 }

En géneral avec ça il n'y a pas besoin de selectionner par classe, mais si c'est necessaire il suffit de faire

var itemMenu = $('hemnu').getElementsByTagName('a');
  for (I=0; I<itemMenu.length; I++) {
     if (itemMenu[I].className == "maclass") {
     }
 }

C'est pas trés long et tu peux selectionner tout ce que tu veux avec cette méthode en etant sur que ta boucle ne tournera que sur les liens de ton menu.

Sinon il y a une petite bibliothéque qui s'appelle "behavior" qui utilise la fonction $ comme selecteur universel par classe, tag, ou id. Cette biblithéque ne sert que de selecteur.

Aprés pour des projets plus grand avec des effets et de l'Ajax, j'ai un gros penchant pour mootools, et dans ce cas effectivement autant utiliser leurs selecteurs.
Modifié par matmat (12 Jun 2007 - 20:13)

mathmax a écrit :
En fait ça dépends du navigateur. Je n'avais testé que sous IE7.

Avec IE7, jquery est un peu plus performant que Prototype.

Avec IE6, c'est l'inverse. Prototype est un peu plus performant que jquery.

Sous FF et Opera par contre, Prototype est franchement plus performant.

J'ai testé aussi sur Netscape 7 et là Prototype remporte largement la bataille tandis que MooTools 1.2dev ne renvois pratiquement que des erreurs.

Au total, les plus performants sont MooTools 1.2dev et ext 1.1b1 mais ce dernier renvois pas mal d'erreurs. Par contre étant donné que c'est MooTools qui publie le test, on peut se demander si le test n'a pas été fait à son avantage...

cssQuery 2.02 est pratiquement toujours le plus lent;

Prototype est le plus compatible et satisfaisant au niveau performances (sauf pour IE7)

Je pense donc en effet que Prototype est un bon compromis. J'ai envie aussi de voir ce que donne MooTools (leur site est très bien fait en tout cas).

Si vous avez d'autre stats ou comparaisons de ce genre, encore une fois, je suis preneur.

Ok, je pensais que tu parlais de firefox


Sous Safari 3 (windows) prototype et mootools sont 2 fois plus rapide que firefox et jquery et css query jusqu'a 6 fois plus rapides

IE7 est plus rapide que IE6 en général, rapidement entérrés par FF et masteurisé par SF.

Je testerais Konqueror à l'occasion.