Lance 10 instances jboss avec struts pour un simple hello world, on en reparle après. Plus simple, lance 100 fois php sur le même code.
C'est sur que si tu charges un framework monstrueux concu pour rendre des choses tres complexe possibles, juste pour faire un simple System.out.println("He, gros, ca va bien, ouaich?"); la consommation memoire va te paraitre quelque peu excessive
Lance 10 instances d'un appli c++ linkee statiquement aux MFC, Qt, GTK, ncurses, kdelib, gtk lib de threading, connecteur db et lib xml, moultes template et tout le trala pour faire un simple cout << "Ouaich, gros!"; tu vas arriver au meme genre de conclusion.
Ecrit une appli metier un tant soit peu consequente en J2EE (pas un forum phpbb quoi), si t'arrives ne serait ce qu'a produire un truc qui marchotte en c++ en 4 fois le temps de dev, ca sera impressionant.
Et a ce moment la, tu comprendras peut etre l'interet de ce genre de langage, c'est pas d'economiser 120ko de ram, c'est tout simplement d'etre capable de resoudre un enorme probleme, et tu auras une petite idee de pourquoi l'idee meme de ton benchmark est completement debile. On s'en fout que ca soit pas ultra optimal en ram, tant que ca repond au probleme, c'est deja un enorme gain.
[^] # Re: La différence principale entre php et c++
Posté par thedude . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 0.
C'est sur que si tu charges un framework monstrueux concu pour rendre des choses tres complexe possibles, juste pour faire un simple System.out.println("He, gros, ca va bien, ouaich?"); la consommation memoire va te paraitre quelque peu excessive
Lance 10 instances d'un appli c++ linkee statiquement aux MFC, Qt, GTK, ncurses, kdelib, gtk lib de threading, connecteur db et lib xml, moultes template et tout le trala pour faire un simple cout << "Ouaich, gros!"; tu vas arriver au meme genre de conclusion.
Ecrit une appli metier un tant soit peu consequente en J2EE (pas un forum phpbb quoi), si t'arrives ne serait ce qu'a produire un truc qui marchotte en c++ en 4 fois le temps de dev, ca sera impressionant.
Et a ce moment la, tu comprendras peut etre l'interet de ce genre de langage, c'est pas d'economiser 120ko de ram, c'est tout simplement d'etre capable de resoudre un enorme probleme, et tu auras une petite idee de pourquoi l'idee meme de ton benchmark est completement debile. On s'en fout que ca soit pas ultra optimal en ram, tant que ca repond au probleme, c'est deja un enorme gain.