En exclusivité, je vous révèle mon code, sous licence WTFPL :
$ echo "Hello World" > index.html
Je vous épargne les tableaux de résultats car je suis relativement sûr de mon coup.
Ou pourquoi il est inutile de benchmarker des "Hello world" qui n'ont aucun sens. Un vrai comparatif demanderait de développer plusieurs applis avec plusieurs frameworks sur plusieurs architectures avec des charges aléatoires en comparant les temps d'accès, de développement et de maintenance et personne n'a encore pris le temps de faire ça car ça dépend aussi d'autres facteurs difficilement quantifiables (expérience, compétences, etc).
Commentaires
NiCoS le 03/09/2008 :
Tu veux dire que c'est bash le framework le plus rapide du monde ? ;-)
~~~~~~>[]
Sinon je te rejoinds complètement...
Sebseb01 le 03/09/2008 :
Personelement je n'utiliserait pas un framework qui fait pas du code w3c complient
==>[]
Didier Misson le 03/09/2008 :
Enfin un truc SIMPLE !
Avez-vous prévu une version française ?
Merci
:p)
David, biologeek le 03/09/2008 :
La licence vous autorise le fork mais ça sera forcément moins rapide que le mien :p
Mat le 03/09/2008 :
Je suis désolé mais je n'ai vraiment pas la même vision des choses ! Le framework idéal à mon avis a plutôt cette tête :
$> cat << EOF > index.html
Hello World !
EOF
D'une part il satisfera les amateurs de chats.
D'autre part, la partie traitement est séparée du texte, ce qui fait gagner un temps fou à la traduction.
Le seul point faible c'est que la licence oblige les utilisateurs à tapisser les murs de leurs toilettes avec une version imprimée du code source.
Bref, je suis complètement d'accord : ça rime à rien ces bench...
Loïc d'Anterroches le 03/09/2008 :
Désolé de t'avoir vexé... ne le prend pas mal comme ça ;-)
David, biologeek le 04/09/2008 :
@Loïc d'Anteroches : qui aime bien châtie bien :-).
Loïc d'Anterroches le 04/09/2008 :
Nous sommes tous les deux des scientifiques pragmatiques, donc bon, on sait tous les deux où se trouve la valeur ajoutée d'un framework de développement web : nulle part ou presque. Dans le sens où aujourd'hui on ne peut rien faire sans et que le choix X ou Y est principalement une question de goût.
D'ailleurs, notre valeur ajoutée est bien au delà de tout ça, grosso modo, je ne gagne pas un rond avec Django & Cie, mais je gagne en utilisant Django pour fournir de l'application de calcul scientifique. Être spécialiste dans un domaine très pointu permet de travailler un mois par an et s'amuser le reste du temps.
Un article qui exprime bien ce que je pense, écrit en 2004, il est toujours d'actualité, particulièrement les 2 derniers paragraphes :
http://www.framasoft.net/article3436.html
David, biologeek le 04/09/2008 :
Même si je te rejoins sur le fond, je pense que l'outil peut faire la différence sur certains points précis. Par exemple si je veux faire de la localisation, je pense que j'aurais plus de facilité avec Django.contrib.gis qu'avec Pluf (dis moi si je me trompe).
C'est intéressant de lire un article aussi vieux et toujours d'actualité :-).
Greg le 04/09/2008 :
Non, Loïc a raison. Si les egos étaient benchmarkés, le sien arriverait certainement dans les toutes premières positions au classement.
Pour moi de toute façon, qui dit fonctionnalités, abstraction et découplage dit overhead supplémentaire pour gérer ces capacités justement, assez mathématiquement.
C'est beaucoup trop facile de livrer un framework configuré au minimum, de lancer des benchs sur un "Hello world" (1) et de se congratuler des résultats. Comme l'illustre David dans son billet, on trouvera toujours une architecture plus merdique mais orientée perfs à tout prix, quitte à user de la plus pure mauvaise foi intellectuelle à dessein.
Et puis cette manie systématique des grands génies méconnus du PHP à cracher dans et sur la soupe des autres, ça me fatigue. Plutôt que d'essayer de proposer des patches ou suggestions constructives d'amélioration, ben non ! Faisons plutôt un post chiant sur le reste du monde pour prouver notre supériorité intellectuelle sur les gueux ignorants. Pfff.
PS: Désolé de nourir un troll de la sorte, mais trop c'est trop.
(1) http://solarphp.com/class/Solar_App_HelloApp (haha)
Greg le 04/09/2008 :
Pardon, le lien est mauvais, c'est http://solarphp.com/class/Solar_App_Hello
Je cite "Absolute minimal "hello world" application for benchmarking."
Au moins dans ce cas précis la couleur est annoncée :D
Bader le 04/09/2008 :
Pour commencer, qui a dit que les geeks ne faisaient pas de marketing ? Le benchmark c'est LE must en terme de marketing chez les geeks et leurs décideurs de patrons.
Il faut comprendre que ces benchmarks sont souvent l'oeuvre de l'auteur d'un framework dont le seul but est de prouver la supériorité de son framework.
D'ailleurs la conception d'un benchmark va privilégier certaines données à la place d'autres. Et donc favoriser le framework qui satisfait le mieux les critères de départ. Le framework de l'auteur part donc encore une fois avantagé.
Preuve en est, Paul M. Jones, l'auteur de Solr et du benchmark dont on parle ici, a été quelque peu agacé par les remarques de Loic qu'il s'est empressé de minimisé pour finir par dire "ne parle pas de ton framework sur mon blog". Bref, en faisant ça il admet que son benchmark sert à comparer SON framework à ses concurrents potentiels.
Concevoir un benchmark idéal relève du simple fantasme. Mais si l'on veut partir sur des fondements stables il faudrait d'abord évaluer quels critères pour quelles besoins.
Et une fois que ça sera réalisé, je pense que le benchmark sera lui aussi inutile. Des choix de critères découlent la meilleure implémentation...
En conclusion à part dans des projets à vocation assez simple : ex libjpeg d'Opéra vs libjpeg libre, faire un benchmark relève pour moi de l'utopie technicienne et de la simple opération de communication geek.
Clochix le 04/09/2008 :
Merci David pour ce post rafraîchissant, les 2 gué-guerres bidon sur les performances des frameworks PHP et des moteurs javascript qui encombrent mes feeds depuis quelques jours ont un parfum assez déprimant de régression à la cours de primaire. Ca fait du bien de prendre un peu de recul. Tous ces geeks n'ont donc jamais entendu que la façon dont on utilise un outil importe plus que ses performances pures ?
Bader le 06/09/2008 :
D'ailleurs c'est Donald E. Knuth lui-même qui disait : "L'optimisation prématurée est la racine de tous les maux (ou presque) en programmation"
http://fr.wikipedia.org/wiki/Donald_Knuth#Autres_id.C3.A9es_notables
Benjamin le 08/09/2008 :
@ Loïc (et aux autres :-)
Prenons un exemple.
Des développeurs travaillent sur un projet mais ne le documentent pas de suite (comme souvent). Avant la fin du dit projet ces personnes pour des raisons personnelles sont amenées à partir.
Le projet doit continuer.
Question.
Le transfert de compétences n'est-il pas plus facile et le code plus aisé à reprendre lorsqu'une application Web a été développé avec un Framework ?
Le cas ou un projet doit grossir et accueille de nouveaux arrivants est valable aussi:
Dans le cas d'un projet non documenté est-il plus rapide de reprendre du code sous Framework (Zend par exemple) ?