Le framework web le plus rapide du monde

Posté en september 2008


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).


15 Commentaires

Tu veux dire que c'est bash le framework le plus rapide du monde ? ;-)

~~~~~~>[]

Sinon je te rejoinds complètement...

1 | NiCoS, le 3 September 2008 à 15h

Personelement je n'utiliserait pas un framework qui fait pas du code w3c complient

==>[]

2 | Sebseb01, le 3 September 2008 à 15h

Enfin un truc SIMPLE !

Avez-vous prévu une version française ?
Merci

:p)

3 | Didier Misson, le 3 September 2008 à 15h

La licence vous autorise le fork mais ça sera forcément moins rapide que le mien :p

4 | David, biologeek, le 3 September 2008 à 15h

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...

5 | Mat, le 3 September 2008 à 17h

Désolé de t'avoir vexé... ne le prend pas mal comme ça ;-)

6 | Loïc d'Anterroches, le 3 September 2008 à 19h

@Loïc d'Anteroches : qui aime bien châtie bien :-).

7 | David, biologeek, le 4 September 2008 à 01h

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

8 | Loïc d'Anterroches, le 4 September 2008 à 09h

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é :-).

9 | David, biologeek, le 4 September 2008 à 13h

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)

10 | Greg, le 4 September 2008 à 15h

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

11 | Greg, le 4 September 2008 à 15h

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.

12 | Bader, le 4 September 2008 à 21h

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 ?

13 | Clochix, le 4 September 2008 à 21h

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

14 | Bader, le 6 September 2008 à 17h

@ 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) ?

15 | Benjamin, le 8 September 2008 à 15h

Ajouter un commentaire


Billets ★ choisis

★ Développer une application RESTful avec Django

Logo associé au billet intitulé Développer une application RESTful avec Django

Après vous avoir expliqué la théorie sur l'architecture REST, rien de vaut un exemple concret pour bien comprendre le mécanisme. J'ai longtemps hésité entre la classique todolist et un agrégateur pour l'exemple mais j'ai finalement opté ...

★ Web social : rendez nous le contrôle de nos données !

Logo associé au billet intitulé Web social : rendez nous le contrôle de nos données !

J'ai lu avec intérêt la Déclaration des Droits de l'Utilisateur 2.0 qui est une excellente idée mais il est vraiment dommage que la réflexion n'ait pas été portée un peu plus loin pour approcher davantage mon ...

★ À la recherche d'un site sémantique

Logo associé au billet intitulé À la recherche d'un site sémantique

Ce billet fait suite à celui intitulé À la recherche du site parfait qui était une ébauche de réflexion sur la structure de mon prochain site. Depuis que je vous ai promis l'avenir du web comme étant sémantique, je ...


© 2004-2010 David Larlet - Licence (presque) libre - Site enfin propulsé par Django et hébergé par Typhon.