8791 sujets
(réponse pour la question qui a été posée : le cache n'est pas activé pour le forum)
pas nécessairement, mais dans l'absolu oui, il y a une petite différence.
après, il y a des solutions de cache php (au niveau appli) qui sont très performantes, et de cache script/template (par exemple smarty) qui le sont relativement autant.
en général c'est surtout sql qui a le dernier mot.
on va dire qu'un script courant, en PHP, ne dépasse pas un certain nombre d'instructions de base pour générer une page (à la limite des includes, echo, des conditions, une ou deux boucles, de la manipulation de tableau...), et cela ne va jamais chercher très loin dans des traitements de fou.
par contre il fait très souvent appel à une/des requête(s) sql, et c'est là que les difficultés commencent, car il s'agit assez souvent de manipuler des tables de grande taille et/ou mal conçues/indexées. la connexion à la base, un update et tout ce qui s'ensuit est nettement plus conséquent que deux includes et trois echo.
donc il est beaucoup plus facile d'être pénalisé au niveau sql que php dans les situations les plus courantes.
QuentinC a écrit :
Donc il vaut mieux avoir un seul fichier php de 50 Ko que 5 fichiers de 10 Ko, c'est ça ?
Parce que j'ai pris l'habitude, pour l'orienté objet de php, de faire une classe par fichier... j'ai tout faux ?
pas nécessairement, mais dans l'absolu oui, il y a une petite différence.
après, il y a des solutions de cache php (au niveau appli) qui sont très performantes, et de cache script/template (par exemple smarty) qui le sont relativement autant.
en général c'est surtout sql qui a le dernier mot.
on va dire qu'un script courant, en PHP, ne dépasse pas un certain nombre d'instructions de base pour générer une page (à la limite des includes, echo, des conditions, une ou deux boucles, de la manipulation de tableau...), et cela ne va jamais chercher très loin dans des traitements de fou.
par contre il fait très souvent appel à une/des requête(s) sql, et c'est là que les difficultés commencent, car il s'agit assez souvent de manipuler des tables de grande taille et/ou mal conçues/indexées. la connexion à la base, un update et tout ce qui s'ensuit est nettement plus conséquent que deux includes et trois echo.
donc il est beaucoup plus facile d'être pénalisé au niveau sql que php dans les situations les plus courantes.
QuentinC a écrit :
Donc il vaut mieux avoir un seul fichier php de 50 Ko que 5 fichiers de 10 Ko, c'est ça ?
Parce que j'ai pris l'habitude, pour l'orienté objet de php, de faire une classe par fichier... j'ai tout faux ?
Certains frameworks on un espèce d'outil qui permet de rassembler les classes les plus utilisées dans un même gros fichier. J'ai fait quelques tests, on réduit effectivement le temps d'exécution. Y'a juste la conso mémoire qui augmente un peu.
Ah, et si on n'a pas de framework et qu'on code tout avec ses dix doigts ?
Côté mémoire même en hébergement mutualisé j'ai droit à 32M, je vois mal comment on peut remplir ça avec du script php... Même pour de l'image ou de l'audio, ça laisse quand même pas mal de marge je crois.
D'ailleurs comment fait-on pour voir combien de mémoire est utilisée pendant un script php ?
Je ne me suis tellement pas penché sur le sujet que je ne sais même pas.
Côté mémoire même en hébergement mutualisé j'ai droit à 32M, je vois mal comment on peut remplir ça avec du script php... Même pour de l'image ou de l'audio, ça laisse quand même pas mal de marge je crois.
D'ailleurs comment fait-on pour voir combien de mémoire est utilisée pendant un script php ?
Je ne me suis tellement pas penché sur le sujet que je ne sais même pas.
Depuis la 5.2, on peut vérifier la conso mémoire aussi bien sous win que sous nux (avant la version windows distribuée ne permettait pas de le faire).
Avec la fonction memory_get_usage(), on récupère la conso actuelle. Et avec memory_get_peak_usage(), on obtient le maximum qu'on a atteint au cours de l'exécution du script.
Et si t'as xDebug, tu peux sortir un profil complet de la conso, fonction par fonction
Avec la fonction memory_get_usage(), on récupère la conso actuelle. Et avec memory_get_peak_usage(), on obtient le maximum qu'on a atteint au cours de l'exécution du script.
Et si t'as xDebug, tu peux sortir un profil complet de la conso, fonction par fonction
a écrit :
par contre il fait très souvent appel à une/des requête(s) sql, et c'est là que les difficultés commencent, car il s'agit assez souvent de manipuler des tables de grande taille et/ou mal conçues/indexées. la connexion à la base, un update et tout ce qui s'ensuit est nettement plus conséquent que deux includes et trois echo.
Imaginons, (ou rêvons) que toute les requetes soient bien faites, qu'elle serait le plus performant entre des echo et des inclusions html directe dans la page?
<?php code ?>
<div>texte</div>
<?php recode ?>
ou
<?php code;
echo '<div>texte</div>';
recode; ?>
matmat a écrit :
Imaginons, (ou rêvons) que toute les requetes soient bien faites, qu'elle serait le plus performant entre des echo et des inclusions html directe dans la page?
<?php code ?> <div>texte</div> <?php recode ?>
ou
<?php code; echo '<div>texte</div>'; recode; ?>
La deuxième serait plus rapide. Il faut éviter de switcher de contexte tout le temps
Maintenant ça dépend combien de <?php ?> sont disséminés dans le code HTML, je ne pense pas que ce soit ultra-significatif.QuentinC a écrit :
Moi j'aime bien cette version-là [...]
Selon Sarah Golemon, dans un post très intéressant ( How long is a piece of string ), c'est la plus lente des forme de chaîne de caractère. Mais je suis d'accord, ça reste une des plus pratiques pour les très longs blocs de texte
a écrit :
c'est la plus lente des forme de chaîne de caractère. Mais je suis d'accord, ça reste une des plus pratiques pour les très longs blocs de texte
C'est surtout pratique pour les formulaires, quand on doit réafficher le contenu de $_POST dans les champs.
echo "<input type=\"text\" id=\"champ\" name=\"champ\" value=\"$_POST
\" />Bof... c'est peu lisible. et la version avec les apostrophes c'est pas tellementmieux.
Modifié par QuentinC (19 Oct 2007 - 09:30)
Bonjour,
sujet très interressant sur les echo
QuentinC, je pensais que l'utilisation des apostrophes dans php augmenter sa rapidité contrairement au double quote. Donc pour moi je prefere avoir.
echo '<input type="text" id="champ" name="champ" value="'.$_POST['chap'].'"/>
que avec les doubles quotes. Ce n'est qu'une question de gouts après je pense. Il reste toujours la possibilité d'ouvrir et de fermer les balises php pour ecrire le formulaire et de ne fait ensuite l'appel que dans le value.
<input type="text" id="champ" name="champ" value="'<?php echo $_POST['chap']; ?>"/>
sujet très interressant sur les echo
QuentinC, je pensais que l'utilisation des apostrophes dans php augmenter sa rapidité contrairement au double quote. Donc pour moi je prefere avoir.
echo '<input type="text" id="champ" name="champ" value="'.$_POST['chap'].'"/>
que avec les doubles quotes. Ce n'est qu'une question de gouts après je pense. Il reste toujours la possibilité d'ouvrir et de fermer les balises php pour ecrire le formulaire et de ne fait ensuite l'appel que dans le value.
<input type="text" id="champ" name="champ" value="'<?php echo $_POST['chap']; ?>"/>
Il y juste un petit probleme avec les echos, c'est la perte de la coloration syntaxique dans les éditeurs de code... c'est un détail mais c'est vrai que c'est pénible. Par contre je crois avoir lu que c'est également une méthode préferable parcequ'elle génere un affichage progressif, alors que dans le cas de l'inclusion direct il faut attendre la fin du script.
QuentinC a écrit :
echo "<input type=\"text\" id=\"champ\" name=\"champ\" value=\"$_POST
Bof... c'est peu lisible. et la version avec les apostrophes c'est pas tellementmieux.
En même temps, là t'aura un problème si y'a des doubles-quotes dans ton champ ou du code html, donc tu sera obligé de passer par une fonction
Du coup ça pose moins de problèmes :$chap = htmlspecialchars($_POST['chap']);
echo '<input type="text" id="champ" name="champ" value="', $chap, '" />';bon je change un peu de sujet... si cela doit faire l'objet d'un nouveau faite le moi savoir.
Il me semble, et je pense que d'autres partagerons mon avis qu'afficher des donnée avec des balises html avec des echos peut devenir trés vites ingerable et "importable". Personellement c'est pour ça que j'utilise des cms, je n'arrive pas a visualiser l'ensemble de mon code xhtml dans les scripts php, d'ou code html pas clair et code php inutilisable pour d'autres projets.
Donc on pense tout de suite a une solution de templates, et naturellement on en vient a ce dire :
Pourquoi utiliser des librairies, des frameworks ou un un script maison alors qu'il existe un systeme de template "natif" xml/xls?.
On se retrouve donc avec le schema suivant :
1. depuis le fichier xls on appel un fichier php
2. le fichier php execute une ou des requetes mysql et genere un fichier xml, on se retrouve la encore avec des echos mais c'est beaucoup plus propre, type :
on peut trés imaginer super systeme de cache à ce niveau qui modifie le xml uniquement quand il y a un changement des données.
3. on affiche ce fichier xls, (on peut de nouveau filtrer les résultats ce qui nous permet dans certains cas pour ne pas multiplier les requetes mysl).
Ce schema s'applique également aux formulaires.
Qu'en pensez vous, la norme xml/xls est-elle suffisament répandut pour pouvoir envisager cette solution?
Qu'en serait-il au niveau des performances, normalement mieux qu'un systeme de template puisque pas de script en plus, mais par contre le traitement du xml/xls par le navigateur (j'y connais rien de ce coté là mais ça à l'air relativement simple, en tout cas plus que la pluspart des systèmes de templates)
De plus un autre avantage c'est l'utilisation simplifier d'ajax, en effet pas de doubles script ou double rendu, un seul fichier xml.
Un autre avantage c'est que celon les cas (petit site ou petite applis) on peut faire une base de donnée uniquement xml sans php avec le même schema (le php modifie directement le xml)
Il y a un cms qui fonctionne avec un système de templates xslt : www.haricow.org
Modifié par matmat (19 Oct 2007 - 18:01)
Il me semble, et je pense que d'autres partagerons mon avis qu'afficher des donnée avec des balises html avec des echos peut devenir trés vites ingerable et "importable". Personellement c'est pour ça que j'utilise des cms, je n'arrive pas a visualiser l'ensemble de mon code xhtml dans les scripts php, d'ou code html pas clair et code php inutilisable pour d'autres projets.
Donc on pense tout de suite a une solution de templates, et naturellement on en vient a ce dire :
Pourquoi utiliser des librairies, des frameworks ou un un script maison alors qu'il existe un systeme de template "natif" xml/xls?.
On se retrouve donc avec le schema suivant :
1. depuis le fichier xls on appel un fichier php
2. le fichier php execute une ou des requetes mysql et genere un fichier xml, on se retrouve la encore avec des echos mais c'est beaucoup plus propre, type :
echo '<pages>';
foreach ($page as $i=>$num){
echo '<pages>';
echo '<title>$title</title>';
echo '<texte>$texte</texte>';
}
echo '</pages>';
on peut trés imaginer super systeme de cache à ce niveau qui modifie le xml uniquement quand il y a un changement des données.
3. on affiche ce fichier xls, (on peut de nouveau filtrer les résultats ce qui nous permet dans certains cas pour ne pas multiplier les requetes mysl).
Ce schema s'applique également aux formulaires.
Qu'en pensez vous, la norme xml/xls est-elle suffisament répandut pour pouvoir envisager cette solution?
Qu'en serait-il au niveau des performances, normalement mieux qu'un systeme de template puisque pas de script en plus, mais par contre le traitement du xml/xls par le navigateur (j'y connais rien de ce coté là mais ça à l'air relativement simple, en tout cas plus que la pluspart des systèmes de templates)
De plus un autre avantage c'est l'utilisation simplifier d'ajax, en effet pas de doubles script ou double rendu, un seul fichier xml.
Un autre avantage c'est que celon les cas (petit site ou petite applis) on peut faire une base de donnée uniquement xml sans php avec le même schema (le php modifie directement le xml)
Il y a un cms qui fonctionne avec un système de templates xslt : www.haricow.org
Modifié par matmat (19 Oct 2007 - 18:01)
changement de programme!
Avant de me lancer dans l'aprentissage de xls, j'ai décider de tester Smarty, et excelente surprise, c'est super rapide et trés souple donc je crois que je faire une transition progressive de mes cms qui rament vers Smarty.
C'est a dire que j'aurais autant de souplesse niveau séparation php/xhtml pour un site jusqu'a 30 fois plus performant!
Avant de me lancer dans l'aprentissage de xls, j'ai décider de tester Smarty, et excelente surprise, c'est super rapide et trés souple donc je crois que je faire une transition progressive de mes cms qui rament vers Smarty.
C'est a dire que j'aurais autant de souplesse niveau séparation php/xhtml pour un site jusqu'a 30 fois plus performant!
je sais que ça peut faire un peu rigoler mais serieusement test le truc, c'est épatant :
La classe et trés facile à mettre en place bien et documentée, elle ne fait que génerer des templates, tu reste maitre de tout ton code php. En gros c'est juste pour pouvoir visualiser ta structure xhtml.
Tu peut mettre autant de templates (header, menu, content...) ou d'inclure que tu veux (classe mysql, ou session...) histoire d'organiser tes scripts de façon super claires et smarty de compile tout ça dans un même script php, donc pas le problème par rapport aux multiples fichier qui est mentionner plus haut.
Il y a un système de cache par fichier, ça c'est super, je ne sais pas si tu as déja travailler avec du cache, c'est bien mais des fois c'est pénible par exemple pour rafraichir le menu tu dois tout rafraichir, là pas ce probléme.
Et le mieux c'est les performances, quelques ms a vide, c'est a dire que grace au compilateur en trés peu de temps ton appli devient plus rapide qu'un code fait mains, à moins bien sur d'avoir son propre compilateur ou de mettre tout dans un même fichier (moi je pas faire ça, je suis pas asser agile de molette)
Enfin bref c'est énormement d'avantages pour aucun inconvenients. En effet quand tu as plusieur sites à gérer et une certaine production, pouvoir réutiliser des modeles te fais gagner en temps fou.
Un petit article de sitepoint si tu veux encore d'autres arguments.
Aller même une petite citation :
Modifié par matmat (20 Oct 2007 - 04:20)
La classe et trés facile à mettre en place bien et documentée, elle ne fait que génerer des templates, tu reste maitre de tout ton code php. En gros c'est juste pour pouvoir visualiser ta structure xhtml.
Tu peut mettre autant de templates (header, menu, content...) ou d'inclure que tu veux (classe mysql, ou session...) histoire d'organiser tes scripts de façon super claires et smarty de compile tout ça dans un même script php, donc pas le problème par rapport aux multiples fichier qui est mentionner plus haut.
Il y a un système de cache par fichier, ça c'est super, je ne sais pas si tu as déja travailler avec du cache, c'est bien mais des fois c'est pénible par exemple pour rafraichir le menu tu dois tout rafraichir, là pas ce probléme.
Et le mieux c'est les performances, quelques ms a vide, c'est a dire que grace au compilateur en trés peu de temps ton appli devient plus rapide qu'un code fait mains, à moins bien sur d'avoir son propre compilateur ou de mettre tout dans un même fichier (moi je pas faire ça, je suis pas asser agile de molette)
Enfin bref c'est énormement d'avantages pour aucun inconvenients. En effet quand tu as plusieur sites à gérer et une certaine production, pouvoir réutiliser des modeles te fais gagner en temps fou.
Un petit article de sitepoint si tu veux encore d'autres arguments.
Aller même une petite citation :
a écrit :
"Combine Smarty's template compilation and PHP's inherent efficiency in generating Web pages, and you've got yourself a winner in the speed race. Smarty also offers extensive functionality, including template functions and variable modifiers, which can be extended using a well-designed plug-in architecture.
All that speed and functionality doesn't come at the price of usability: the learning curve is no steeper than that of other template engines."
Cheah Chu Yeow - (sitepoint)
Modifié par matmat (20 Oct 2007 - 04:20)