Discussion :

[Freem]

Et c'est quoi la réponse si évidente à cette question ?
J'ai déjà lu des débats sur compilé vs interpreté, mais j'ai du mal à comprendre pourquoi je vois beaucoup d'application Java assez basique et pourtant très lente comparé à la même chose en PHP. Facebook qui est une application qui doit nécessiter une performance de malade a pourtant fait le choix d'un PHP (adapté). Et ce n'est qu'un exemple parmi d'autres.

Autant, je comprends le côté industriel de JAVA, et la fulltitute d'outils qui existent pour créer une application robuste. Autant sur la performance je m'interroge. En dehors de la preche, sur quoi se base Andi pour dire que Java est trop lent ?

La principale cause des lenteurs d'un programme, ce n'est pas le langage, mais le programmeur.
Dire:
_ JAVA est plus rapide que C++
_ JAVA est plus lent que C++
ne veut juste rien dire, puisque ça va dépendre du niveau d'expertise du type qui a fait les benchmark dans les divers langages.
Par exemple, en C++, si tu ignores que tu peux passer des références et que tu ne passes donc que des objets en copie, tu va multiplier les appels constructeurs/destructeurs, ce qui ralentira potentiellement énormément le programme comparé au même fait en JAVA (puisque java n'a que des références mais pas de valeurs en dur, aux dernières nouvelles).

Bon, après, normalement, si les langages sont maniés par des gens qui les maîtrisent, C++ devrait être plus rapide que JAVA, lui même plus rapide que PHP.
La raison, c'est qu'en C++, toutes les optimisations sont faites à la compilation (qui elle est la plus lente des 3 langages, en revanche), en JAVA tu en auras certaines faites à la compilation et d'autres à l'interprétation (traduction VM<->machine. Par exemple, pour utiliser les registres d'un proc 64bits) et en PHP, ce sera uniquement à l'exécution qu'il y aura des optimisations.
Sauf que comme l'optimisation est un processus coûteux, PHP en sautera certaines qui ne seraient pas rentables, ce qui résulte en une plus grande lenteur.

Un autre point qui joue en défaveur de PHP, c'est l'absence de typage. Le compilateur doit donc deviner le type, et celui-ci peut changer d'un moment à l'autre, je crois? Ca implique encore des calculs supplémentaires.

Mais au final, je pense que le plus important facteur de ralentissement reste le code source.

[rimram31]

...Facebook qui est une application qui doit nécessiter une performance de malade a pourtant fait le choix d'un PHP (adapté)...

Adapté, tu me fais rire, du coup ce thread m'aura fait un peu creuser le sujet ... http://www.zdnet.com/blog/facebook/f...this-year/8725 tout le monde n'a pas les moyens de coder son propre compilateur ... tu auras d'autres éléments de réponse ici: http://www.zdnet.com/blog/facebook/w...tched-php/9536 on est assez éloigné des problèmes de tous les jours des développeurs PHP. En 2007, fb avait besoin de 30.000 serveurs pour environ 200M d'utilisateurs, à ce régime, il est clair qu'ils vont tout faire pour gérer au mieux leurs coûts d'infrastructure et donc probablement, peu a peu, abandonner PHP.

Edit: Et du coup, je me suis rappelé que Cassandra a été développé par fb avant de passer sous Apache, à ma connaissance, c'est du Java.

[David_g]

Facebook avait utilisé PHP principalement car il était facile de trouver des développeurs PHP pour leur besoin énorme de croissance tant au niveau code (mais aussi au niveau infra).
Cependant on a vu avec hiphop que PHP avait commencé à leur poser problème (performances) et qu'ils ont travaillé pour non pas s'en séparer (vu leur base de code c'est illusoire) mais pour contourner le problème etc.

[fxrobin]

En dehors de la preche, sur quoi se base Andi pour dire que Java est trop lent ?

Justement si cela avait été un peu étayé ça aurait été intéressant, mais là c'est creux ... vide, nada.

Pire, cela fait penser à ceux qui faisaient "mumuse" avec des Applets en 1997 dans Netscape Navigator ou dans IE 4 et qui disaient (à raison) "Java c'est lent" ... mais depuis (on est en 2012 je le rappelle) ce n'est plus vrai et malheureusement les vieilles idées reçues ont la peau dure. Java a pris un sérieux "boost" avec la 1.4.2, puis la 1.5 et encore la version 6 ... et la 7 c'est du bonheur.

A chaque version, les performances de la JVM (avec du bytecode client JAVA inchangé) sont meilleures.

Bref, un argumentaire de bistro émanant d'Andi Gutmans, ça fait un peu pitié.

[el_slapper]

(.../...)

A chaque version, les performances de la JVM (avec du bytecode client JAVA inchangé) sont meilleures.
(.../...)

Ca ne sera jamais aussi bon que du natif assembleur ou C micro-optimisé au poil de derche.

Mais, pour une très grande majorité d'applis, ça suffit, aujourd'hui. Ca n'a pas toujours été le cas, et c'est une réputation qui va être difficille à décoller de la semelle.

[rimram31]

Ca ne sera jamais aussi bon que du natif assembleur ou C micro-optimisé au poil de derche...

Ca me rappelle le bon temps de ces débats et a cette époque, vu du Java plus rapide que du C, because HotSpot était plus futé que le développeur qui n'avait pas utilisé toutes les bonnes options d'optimisations ... Cela étant dans ce débat, n'oublions pas que la partie strictement "calcul" dans une application web reste limitée et 100x plus lent peut au final ne se traduire que par un x3 ou x4 (et pour peu que tu fasses du templating de ouf dans ton IHM ...).

[fxrobin]

Ca ne sera jamais aussi bon que du natif assembleur ou C micro-optimisé au poil de derche.

C'est certain. Je te rejoins sur ce point. D'ailleurs quand on le souhaite on appelle du code natif avec JAVA (JNI) ... donc on a toujours la possibilité de le faire, mais on perd le "compile once, run anywhere" ...

De plus, je me vois mal faire un site web en JSF + Ajax + Transactionnel + Load Balancé en assembleur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mov eax, [ebx]

A une époque je m'amusais même à ré-écrire mes routines d'accès à la carte vidéo (mode X 13h pour ceux qui se souviennent) avec Triple Buffering et tout tout ... et un jour est arrivé Direct X ... plus personne ne fait sans Direct X aujourd'hui.

[alex_vino]

j'ai du mal à comprendre pourquoi je vois beaucoup d'application Java assez basique et pourtant très lente comparé à la même chose en PHP. Facebook qui est une application qui doit nécessiter une performance de malade a pourtant fait le choix d'un PHP (adapté). Et ce n'est qu'un exemple parmi d'autres.

Si tu fait attention lorsque tu utilises Facebook tu ne change pas beaucoup de page (enfin lors mon utilisation en tout cas), beaucoup de choses se fait en Ajax. La problématique de Facebook est surtout lié a la rapidité d'acces aux données et ce, n'est pas directement lié au language de programmation. D'ailleurs Facebook a en interne ses propres outils PHP et bases de données sur mesure, donc ce n'est pas tellement facile de comparer Facebook et PHP.

[rimram31]

...D'ailleurs Facebook a en interne ses propres outils PHP...

Je résume, fb réécrit memcache et ses drivers réseau, du C donc, écrit Cassandra, un NoSQL en Java, un compilateur PHP/C++ ... je ne serais pas surpris de trouver quelques bricoles en Python et autres langages, bref, fait ce qu'on fait tous dans ces cas là, utiliser les technologies adaptées au problème donné.

A miboo plus haut, au sujet des applications Java "lentes", pour information, bon nombre de sites web, c'est vrai plutôt "pro", sont développés sur des solutions comme Liferay, Nuxeo ... et autre ametys, hippocms. Il est vrai qu'in fine, les pages ne sont pas suffixées en .jsp ...

[pcaboche]

Facebook avait utilisé PHP principalement car il était facile de trouver des développeurs PHP...

Non, Mark Zuckerberg a utilisé Facebook parce que c'est ce qu'il maîtrisait le mieux, qu'il codait ça pendant ses études, et qu'il devait faire vite pour piquer l'idée aux jumeaux trop occupés à faire du rameur.

Une fois bien lancé, il s'est trouvé coincé avec ce choix technologique, il a dû faire avec et trouver des solutions (parfois assez compliquées). Aujourd'hui fb se trimballe encore ce choix historique, même s'ils essayent de le remplacer petit à petit par autre chose (mais ça prend du temps, Rome ne s'est pas construite en un jour).


Bref, quand on a des deadlines super serrées, on ne choisit pas forcément la solution la mieux adaptée mais la plus accessible, c'est-à-dire :
- celle qu'on maîtrise le mieux (on ne perd pas de temps à devoir apprendre quelque chose de nouveau)
- celle qui respecte le budget (ça sert à rien de choisir une technologie qui fait le boulot à notre place si on ne peut pas se l'offrir à cause du coût des serveurs ou autre)

Une fois ce choix effectué, généralement on l'assume pendant assez longtemps par la suite. Vu qu'on ne peut pas se permettre de tout réécrire du jour au lendemain, on fait des patches et des bidouilles pour que ça continue de tourner.

Donc Mark Zuckerberg a choisi PHP parce que c'était plus accessible pour lui que le reste (y compris Java) et a recruté plein d'ingénieurs par la suite par rapport à ce choix historique (et non pas parce qu'il y avait plein de développeurs PHP : il y avait autant, si ce n'est plus, de développeurs Java en 2004).

[alex_vino]

Je résume, fb réécrit memcache et ses drivers réseau, du C donc, écrit Cassandra, un NoSQL en Java, un compilateur PHP/C++ ... je ne serais pas surpris de trouver quelques bricoles en Python et autres langages, bref, fait ce qu'on fait tous dans ces cas là, utiliser les technologies adaptées au problème donné.

Je n'ai jamais dit que Facebook a creer ses propres languages de programmation, drivers... ne fait pas dire ce que je n'ai pas dit, surtout en presentant les extremes.
C'est juste que Facebook a developer certains de ses propres outils, et pas seulement concernant le PHP (n'est ce pas), pour pallier a de nouveaux problemes majeurs que les outils existant ne sont pas toujours capables de repondre (ou de maniere inadaptee), tel les donnees par exemple.
Facebook n'est pas la seule entreprise a le faire loin de la.

[rimram31]

Je n'ai jamais dit que Facebook a creer ses propres languages de programmation...

Ca ne t'étais pas adressé, c'est moi qui résumait le fait que fb a fait bien d'autres choses que du PHP sur sa plateforme C, C++, Java ... et que ce type d'application n'est pas le meilleur exemple d'utilisation du PHP.

pcaboche a probablement raison, le choix de Mark Zuckerberg est historique et logique pour un démarrage, après, tu fais avec.

[camus3]

Personne ne va laisser tomber la techno qu'il utilise parce qu'un gars payé pour promouvoir PHP/Zend affirme qu'elle est la meilleurs, ce débat n'a pas réellement de sens et le gars ferait mieux de s'occuper de PHP6 si il veut vraiment que les dév continuent d'utiliser son langage ...

[el_slapper]

Ca me rappelle le bon temps de ces débats et a cette époque, vu du Java plus rapide que du C, because HotSpot était plus futé que le développeur qui n'avait pas utilisé toutes les bonnes options d'optimisations ... Cela étant dans ce débat, n'oublions pas que la partie strictement "calcul" dans une application web reste limitée et 100x plus lent peut au final ne se traduire que par un x3 ou x4 (et pour peu que tu fasses du templating de ouf dans ton IHM ...).

C'est pour ça que j'ai précisé "au poil de derche". C'est du grand art, et pas à la portée de tout le monde(moi le premier).

La partie "Calcul", ça dépend de ton site web. Si c'est du E-commerce, effectivement, ça ne va pas aller loin, et la performance du langage de calcul sur serveur, on s'en moque. Si c'est une appli traitant des données massivesde manière systématiques(je pense en particulier au jeu en ligne, il y en a sans doute d'autres), ça devient par contre critique. Mais bon, une majorité des problèmes de performances ne sont PAS liés au langage, mais à l'algorithmique.

C'est donc, dans la plupart des cas, un faux problème. Et je crois qu'on est d'accord sur la conclusion.

[rimram31]

...Mais bon, une majorité des problèmes de performances ne sont PAS liés au langage, mais à l'algorithmique...

On est bien d'accord et pas toujours aisé d'ailleurs d'y voir clair quand on a une plateforme "qui s'emballe" (ou plutôt qui s'étouffe :-)) c'est à ce moment là qu'on cherche une aiguille dans une motte de foin. On en a pas trop parlé ici, mais dans ce domaine, Java a quand même quelques longueurs d'avance coté monitoring, ne serais-ce qu'un simple kill -3.

Mais on en revient toujours a la même conclusion, nombre de projets web n'auront pas besoin d'aller jusque là.

[Freem]

A chaque version, les performances de la JVM (avec du bytecode client JAVA inchangé) sont meilleures.

Bref, un argumentaire de bistro émanant d'Andi Gutmans, ça fait un peu pitié.

J'ai envie de dire que les compilateurs de chaque langage s'améliorent à chaque version. Niveau argumentaire pitoyable, tu l'as rejoint sans vouloir te manquer de respect

De nos jours, je ne suis pas persuadé que les dev C++ les plus pointus aillent bidouiller le binaire final pour gagner en perf ni inclure de l'assembleur.
C'est vachement plus simple de filer les options d'optimisation au compilo.

Maintenant, vu que la question ici concerne PHP: l'interpréteur PHP a-t-il des "options de compilation" ou trucs du genre pour améliorer les performances sans toucher au code ?


Après, si on veut vraiment choisir le meilleur langage, je pense que le meilleur, c'est celui déjà utilisé. Si on tape dans les limites, il faut ensuite voir si quelqu'un dans l'équipe maîtrise un langage mieux adapté et qui peut s'interfacer avec le 1er.

Parce que bon, la formation c'est pas donné, sans compter que, pendant ce temps, le travail n'avance pas. Et si en plus il faut réécrire une vieille appli... les coûts et les délais explosent pour une perte de stabilité (historique des bugs corrigés).

[fxrobin]

J'ai envie de dire que les compilateurs de chaque langage s'améliorent à chaque version.

Malheureusement tu me fais dire ce que je n'ai pas dit.

Je n'ai pas dit que les autres de s'étaient pas améliorés, j'ai juste dit que Gutmans s'était figé dans le temps en ce qui concerne JAVA ... version 1996 ... et qu'il a dû oublié d'étudier sérieusement les autres plateformes que la sienne dans l'intervalle et je trouve cela consternant.

Niveau argumentaire pitoyable, tu l'as rejoint sans vouloir te manquer de respect

J'ai quand même fourni quelques benchmarks et d'autres contributeurs aussi, je pensais avoir un peu argumenté mon point de vue ... ou alors tu n'as pas tout lu, sans vouloir te manquer de respect

[Elendhil]

J'ai déjà lu des débats sur compilé vs interpreté, mais j'ai du mal à comprendre pourquoi je vois beaucoup d'application Java assez basique et pourtant très lente comparé à la même chose en PHP. Facebook qui est une application qui doit nécessiter une performance de malade a pourtant fait le choix d'un PHP (adapté). Et ce n'est qu'un exemple parmi d'autres.

Autant, je comprends le côté industriel de JAVA, et la fulltitute d'outils qui existent pour créer une application robuste. Autant sur la performance je m'interroge. En dehors de la preche, sur quoi se base Andi pour dire que Java est trop lent ?

Pour les performances le Benchmark cité plus haut parle de lui même.

Voila le résultat sur les 10 petits algos testés. Ce benchmark semble plus intéressant que ce que l'on trouve d'habitude par son concept. C'est totalement open source et tout le monde peut soumettre un nouveau code qui améliore les performances de son langage sur un des algos.



source: http://shootout.alioth.debian.org/

Apparemment Php aurait besoin d'un peu d'aide , donc ceux qui trouvent que les performances ne sont absolument pas réalistes peuvent essayer d'améliorer le code et le soumettre.

Pour en revenir à ceux qui disent que java est lent c'est souvent pour deux choses qui donnent une vision faussée.
La première c'est les applets java qui semblent lente mais c'est surtout le temps que la jvm se charge, on a pas ce problème avec le javascript vu que le moteur est partie intégrante du navigateur. Et pour flash vu qu'il y a de la pub flash sur chaque page il est toujours en mémoire.

La deuxième c'est surtout sous linux vu que par défaut c'est souvent la jvm OpenJDK qui est installé avec lequel certains programmes sont très lents ou instables.
Ce qui fait que sur les serveurs les gens qui travaillent avec java la remplace par celle d'oracle.
Mais bon cela devrait s'améliorer avec Java 7.

[transgohan]

Pour les performances le Benchmark cité plus haut parle de lui même.

Voila le résultat sur les 10 petits algos testés. Ce benchmark semble plus intéressant que ce que l'on trouve d'habitude par son concept. C'est totalement open source et tout le monde peut soumettre un nouveau code qui améliore les performances de son langage sur un des algos.



source: http://shootout.alioth.debian.org/

Apparemment Php aurait besoin d'un peu d'aide , donc ceux qui trouvent que les performances ne sont absolument pas réalistes peuvent essayer d'améliorer le code et le soumettre.

Pour en revenir à ceux qui disent que java est lent c'est souvent pour deux choses qui donnent une vision faussée.
La première c'est les applets java qui semblent lente mais c'est surtout le temps que la jvm se charge, on a pas ce problème avec le javascript vu que le moteur est partie intégrante du navigateur. Et pour flash vu qu'il y a de la pub flash sur chaque page il est toujours en mémoire.

La deuxième c'est surtout sous linux vu que par défaut c'est souvent la jvm OpenJDK qui est installé avec lequel certains programmes sont très lents ou instables.
Ce qui fait que sur les serveurs les gens qui travaillent avec java la remplace par celle d'oracle.
Mais bon cela devrait s'améliorer avec Java 7.

Ce benchmark est tout à fait hors de contexte pour tous les langages non compilés... Car les tests effectués ne travaillent pas sur de la mémoire allouée dynamiquement. Donc en gros 95% du travail est fait à la compilation en C (langage parmi d'autres)... Changes le tout par des allocations dynamiques et là tu verras que la soit disante super moyenne va exploser !

Proposes une suite de benchmark la prochaine fois qui ne soit adapté à la fois aux langage compilés et interprétés sinon cela n'a pas de sens. Je peux tout à fait te montrer des benchmarks montrant qu'une fusée dans l'espace va plus vite qu'une Porsrche avec la même puissance. Ah bah oui... il y a pas le frottement de l'air dans l'espace... dommage que mon test n'en prenne pas compte.

[alex_vino]

Ah bah oui... il y a pas le frottement de l'air dans l'espace...

et les forces appliquées a ta fusée tres faibles

Dans le benchmark c'est le compilateur Mono qui est utilisé pour les languages .Net et il est effectué sous Unix. .Net est surtout prévu pour une architecture Windows (surtout ASP.Net / IIS) donc les statistiques pour ces languages Microsoft ne veulent pas dire grand chose et sont faussées.