Avez-vous déjà testé la mémoire que prenait PHP avec vos script ?

[Sephi-Chan]

N'empêche que t'as honte de montrer du code ! -.-


Sephi-Chan

[Argorate]

Si c'était le cas j'aurais pas montré mon code dans certains postes de demande d'aide :p
M'enfin faudra que je compare avec d'autres de mes programmes, je trouve ça intéressant de mesurer la quantité de mémoire utilisé...

[Sephi-Chan]

C'est jamais du vrai code que tu montres. Toujours du tronqué, simplifié ou autre. :p
Quant à la RAM, tu relativises vachement quand tu vois que les dédiés à 15€/mois embarquent 2Go.


Sephi-Chan

[Allwise]

Pour ma part les seules fois où j'ai eu des problèmes avec la RAM, c'était avec GD et les images haute résolution, ou quand j'avais à faire à des gros fichiers : traitement de fichiers logs de plusieurs Go parfois, et traitement de XML. Mais à part pour GD et les images de + de 2 Megapixels si je me souviens bien, ça n'a jamais été bloquant.

Mes tests :
Avec Zend Framework mode MVC, autoloading, quelques plugins : 2.25 Mo pour une page qui suit tout le process de dispatching et fait quelques requêtes SQL.
Pour un site pro sous Joomla très chargé en plugins et qui fait beaucoup de requêtes SQL, beaucoup de traitements : 9.25 Mo sur un serveur, contre 9 en local ( c'était pour noter la petite différence qu'il peut y avoir entre des configs différentes ).
Pour un site maison MVC type blog mais procédural : 768 kb.

Conclusion :
Je sais pas quelle conclusion en tirer, mais je pense que pour arriver à avoir un problème de RAM faut vraiment y aller comme un bourrin, ou avoir un serveur sous-dimensionné par rapport au besoin effectif.

J'ai déjà eu des soucis de montée en charge sur le site maison MVC mais ceux-ci étaient je pense davantage liés à la config d'Apache qu'à mes scripts PHP. Config : ancienne dedibox à 30 €. Nombre de connectés en même temps : + de 400. Avec l'offre supérieure et une gestion plus fine du cache du contenu statique, je n'ai plus rencontré ce problème pour des montées en charge supérieures.

[php_addict]

toi tu n'utilise pas de framework...non ?

Non non, je m'en passe très bien malgré se qu'on pourra en dire

c'est bien ce que je voulais dire

donc pour résumer les framework et la POO sont plus gourmand en mémoire même si ce n'es pas un problème pour un serveur dédier...

vous allez me dire: oui mais en POO le code est "plus facilement maintenable", ok mais avec un bon procédural aussi

avec mon MVC procédural fait maison je ne pense pas que j'atteigne un jour 2Mo...

je me pose la question: economiser les temps d'execution et la memoire n'est t'il pas tout de meme une bonne chose tout de même?
est ce que si plus un script boiffe de mémoire, alors plus il y a consomation d'energie (c'est mon côté ecolo )

Code PHP :

<?php 

if($_memoire_SERVER=='gourmand')

{

echo 'bobo à la planète ;-)';

} 

[Sloop]

Pfff ... On ressort le vieux chapelet : "Framework, c'est naze ... blabla... blabla ..." ?

PS : Je ne dirais rien par rapport à cette probable volonté de remettre une nieme fois le sujet des frameworks. Et c'est pas l'envie qui m'en manque.

[Sephi-Chan]

vous allez me dire: oui mais en POO le code est "plus facilement maintenable", ok mais avec un bon procédural aussi

Non. Je suis désolé, mais avec un procédural, aussi beau soit-il, tu n'auras pas la souplesse de l'objet. Tu n'as pas d'héritage, ni d'interface, ni d'encapuslation, etc. Si on a inventé la POO, ce n'est pas pour rien : ça apporte réellement beaucoup.

Ensuite, économiser les ressources processeur, c'est effectivement plus écologique : un processeur au repos consomme moins.

Ne pas charger la RAM ne consomme pas moins que de la bourrer comme un dingue. D'autant que si on la remplit, c'est qu'on cache, donc qu'on économise des ressources. La RAM doit être utilisée. Ça n'a pas de sens de l'économiser (encore plus sur un serveur dédié où la RAM inutilisée est gâchée, puisque vous êtes le seul à pouvoir l'utiliser).

Et puis vos systèmes maison n'ont pas de gestionnaire de cache bien pensé, donc au final vous ne pouvez pas mettre en place simplement et efficacement (ce que vous ferez ne sera pas éprouvé par une communauté entière) les systèmes qui permettent d'économiser des ressources.

Ça ne sert à rien d'essayer de se rassurer en vous disant que vous faîtes le bon choix de faire l'impasse sur la POO… Un choix, ça se fait et ça s'assume. ^^


Sephi-Chan

[php_addict]

PS : Je ne dirais rien par rapport à cette probable volonté de remettre une nieme fois le sujet des frameworks. Et c'est pas l'envie qui m'en manque.

ce n'est pas une volonté de ma part polémiquer sur ce sujet, c'est juste pour me faire une opinion sur ce sujet

Ça ne sert à rien d'essayer de se rassurer en vous disant que vous faîtes le bon choix de faire l'impasse sur la POO… Un choix, ça se fait et ça s'assume.

ce n'est pas pas non plus pour me rassurer, mais dans mon cas j'assume le fait qu'en POO je suis une vrai quiche et mieux vaut pour moi un code procédural pas trop mal foutu qu'un mauvais code POO

merci pour toutes vos opinions

[Allwise]

Allez, je me relance dans le débat vieux comme le monde

Je serais pas aussi catégorique en ce qui concerne les avantages de la POO sur le procédural.
En fait, je pense que la complexité à maintenir et faire évoluer une application en procédural est facteur du nombre de lignes de code du projet.
Plus le projet est gros, plus il nécessite de recourir à la POO. Ou, à la limite, si un projet est composé de petits traitements très indépendants les uns des autres, la POO n'est pas indispensable.

Il m'arrive de développer des mini applications, en général des backoffices, pour lesquelles je préfère faire du procédural viteuf parce que je sais que je n'aurai besoin ni d'héritage, ni d'encapsulation..., et que l'appli est vouée à être figée dans le temps, à ne jamais évoluer. Et pour ces applis là, l'utilisation d'un Framework ne m'apporte rien. Ça n'empêche pas de séparer les couches MVC.

Mais bon voilà, c'est une question d'équilibre. Le procédural c'est pas de la merde, et la POO c'est pas de la magie. On fait tous des petits scripts au quotidien ( enfin je sais pas vous mais ça m'arrive souvent ) pour automatiser des tâches : traiter des fichiers, des flux, spammer ^^... Bien souvent ces scripts ne dépassent pas les quelques centaines de lignes de code et n'évolueront pas ou répondront à un besoin ponctuel. C'est pas la peine de s'embêter à dégager les entités du projet, à créer des classes etc... quelques fonctions qui vont bien sont largement suffisantes.

Pour le développement d'un jeu web par contre, si l'utilisation d'un framework ne me paraît pas indispensable ( c'est au cas par cas ), l'utilisation de la POO, si. Et je rejoins Sephi, se priver de la POO pour grappiller un chouilla de RAM, je serais parfaitement d'accord pour les systèmes qui en dispose d'une quantité très limitée... Mais quand on a plusieurs Go de RAM à sa disposition, c'est un choix qui n'a aucun sens.

D'ailleurs, y a-t-il vraiment des gens qui choisissent le procédural parce que ça fait économiser ? Ou c'est par défaut de pouvoir faire autrement ( POO) ? C'est quoi qui te motive à renier la POO Argo, sinon que tu - je présume - tu ne la maîtrises pas ? :d

[Shudrum]

est ce que si plus un script boiffe de mémoire, alors plus il y a consomation d'energie (c'est mon côté ecolo )

Code PHP :

<?php 

if($_memoire_SERVER=='gourmand')

{

echo 'bobo à la planète ;-)';

}