PRINT vs ECHO

John Gallet

12/05/2004 à 15:43

je cause): mis à part le fait que le echo soit plus rapide que le print,
y'a t'il une différence fondamentale qui fasse que l'un soit préférable
à l'autre?

Mis à part ça, je n'en vois pas.

Ce que tu peux retenir de tout ce fatras est que :

1) si tu t'en souviens au moment où tu l'écris, il n'est pas plus mal
d'utiliser echo au lieu de print (pour le cas où tu étais même au
courant que print existe...). Réserver printf pour l'affichage formatté
des données. Et ne pas chercher à savoir s'il vaut mieux utiliser printf
ou number_format ;-)

2) si tu veux faire des manipulations de chaînes de caractères (toujours
une opération coûteuse dans tous les langages) il vaut mieux en général
éviter la fonction regexp quand son équivalent str* existe car les
regexp sont très puissantes mais souvent gourmandes.

3) (et j'aurais même dû le mettre en premier) on n'optimise pas un
script sans savoir ce qui lui prend du temps. Une fois qu'on le sait, on
s'attaque évidemment aux traitements les plus longs, ça ne sert à rien
de gagner 50% de temps sur 1ms (0.5ms) alors qu'on peut gagner 10% sur 1
seconde (100ms).

4) l'optimisation des poils de cul (1) finit par faire gagner du temps
CPU quand tu fais le traitement des milliers de fois dans une boucle, ou
dans les fonctions appelées plus de 5-6 fois au cours du script,
personne ne le conteste. A part ça, sur une exécution unitaire du script
ça reste... de l'optimisation de poils de cul.

Bref comme d'habitude il faut être conscient de ce que l'on fait et de
prendre une décision en étant informé. Si utiliser une regexp te fait
gagner 10 lignes de code par rapport à ses équivalents en str*, je doute
qu'il faille se poser la question duquel est le plus performant si tu ne
fais pas le traitement dans une boucle ou dans une fonction appelée très
souvent dans le code.

a++
JG

(1) tout respect gardé auxdits poils de cul

Jean-Marc Molina

12/05/2004 à 17:23

Bonjour,

Pour mesurer les performances nous utiliserons l'utilitaire 'ab' fournit
avec Apache. Il effectuera un total de 1000 requêtes par 20 requêtes

simultanées.

Est-ce que cet outil est disponible pour la distribution Windows de Apache ?
Dans mon dossier « bin » j'ai du :
htdigest.exe
htpasswd.exe
logresolve.exe
rotatelogs.exe
...

Mais pas de programme « ab ».

Sinon pour des benchs je vous conseille aussi le package Benchmark de PEAR.

JM

CrazyCat

12/05/2004 à 17:23

John Gallet wrote:

3) (et j'aurais même dû le mettre en premier) on n'optimise pas un
script sans savoir ce qui lui prend du temps. Une fois qu'on le sait, on
s'attaque évidemment aux traitements les plus longs, ça ne sert à rien
de gagner 50% de temps sur 1ms (0.5ms) alors qu'on peut gagner 10% sur 1
seconde (100ms).

Genre préférer utiliser 1 requète SQL comportant des "left join" plutot
que 3 requetes sql.
de toutes manières, je suis anti-print parce que ça me rappelle trop mes
débuts en basic (vous avez connu les ZX81 et les MSX?)

--
Tout sur les eggdrops
http://www.c-p-f.org
ML @

tyoup

12/05/2004 à 17:23

KDO wrote:

Bonjour,

Suite à un thread de J.Gallet j'ai commis un article trop long pour etre
publié ici. Son titre :

PRINT vs ECHO expliqué aux glands, aux neuneux et aux connards qui se la
pètent PERL

URL : http://www.zpmag.com/articles/echo.html

Salutations

KDO

-- cite --

%right T_PRINT
%token T_ECHO

le %right associé à T_PRINT nous confirme bien que (pour simplifier)
'print' peut se retrouver à droite d'une expression (donc qu'il est
évaluable).

-- cite --

yacc expliqué aux glands, aux neuneux et aux connards qui se la pètent
je sais tout : à paraître

--
tyoup

Armel FAUVEAU

12/05/2004 à 17:25

Bonjour,

Certes il existe des différences entre les 2 fonctions, mais
tellement minimes qu'on ne voit pas pourquoi modifier tout son code.

Je confirme à nouveau :)

Perso je n'ai rien appris de fondamentalement nouveau sur les différences
profondes entre echo et print, m'enfin peu importe. L'exposé de KDO en aura
probablement éclairé certain. Et c'est tant mieux. Maintenant, quant à la
preuve par les mesures effectuées par KDO, j'y reste peu senssible : 90.5
req/s contre 88.7 req/s. Et puis ? J'irais même plus loin dans la mesure ou
je me suis moi même amusé à rejouer ce bench sur un de mes serveurs, dans
les conditions proposées par KDO (stress via Apache Bench, 1000 requêtes,
etc.). Voici ce que j'observe :

Serveur P4 @ 1.8 Ghz / Linux 2.4.18 / PHP 4.3.4

echo.php : 174.03 req/s
print.php : 174.70 req/s
echo.php : 182.48 req/s
print.php : 180.28 req/s
echo.php : 169.84 req/s
print.php : 175.01 req/s
...and so on.

Je me suis également amusé à mesurer tout cela différement. L'idée était
d'attaquer les scripts en CGI pure et de mesurer les temps via la commande
time (d'Unix). Je me détache donc totalement du Web. Il n'est plus question
ici d'attaquer un serveur en HTTP et de mesurer les temps via Apache Bench.
Ca donne quoi :

#! /bin/sh
for (( i=1; i<P0; i++ ))
do
php -q $1
done
---------
time ./bench.sh echo.php > echo.log

real 0m40.924s
user 0m33.480s
sys 0m7.350s
---------
time ./bench.sh print.php > print.log

real 0m41.182s
user 0m33.490s
sys 0m7.250s
---------
time ./bench.sh echo.php > echo.log

real 0m41.138s
user 0m33.630s
sys 0m7.280s
---------
time ./bench.sh print.php > print.log

real 0m41.061s
user 0m33.390s
sys 0m7.440s
---------
...and so on again !

Je pourrais continuer et rejouer ces benchs indéfiniement, cela ne
changerait rien.

J'en conclu quoi ? Loin de moi l'idée de remettre en cause le fait que,
techniquement, echo ne peut-être que plus rapide que print. Je ne le
contesterais pas. Et sur un jeu large de test large, les mesures tendent à
le montrer. C'est rassurant, parceque c'est logique. Donc tant mieux :)

Maintenant, on remarquera que les différences observées sont clairement du
domaine de la curiosité. Tant sur la première série de bench, que sur la
seconde, il arrive même que les conditions soient plus favorables à print
que à echo. Et pour cause. D'une part les mesures sont fatalement perturbées
par l'environement et le contexte. Il suffit qu'un sync au niveau
filesystem, ou tout autre intervention prioritaire, interviennent pendant
une série de mesure pour en changer les résultats, c'est évidement. Et
personne ne s'en étonnera. D'autre part, l'idée même de mesurer des choses
aussi atomiques n'a pas réellement de sens. Et c'est surtout très éloigné de
conditions réelles, j'entends, en production. Enfin, si ma formation
scientifique m'a bien enseigné quelque chose, c'est bien le fait qu'en terme
de mesure, il convient toujours d'être prudent. J'aurais ainsi tendance à
concidérer que les différences observées sont plus expliquable par les
erreurs de mesures, que par autre chose. Comparer 0m41.138s et 0m41.061s
suggère de souligner un écart de...77 ms. Je m'amuse :)

Bref, bref, loin de moi l'idée de polémiquer autour de tout ceci. Sans
compter que, en ce qui me concerne et comme le rappelais Pimousse, je
m'étais effectivement déjà exprimé sur le sujet. Mais force est de constater
que, 2 ans plus tard, je confirme à nouveau la chose :) Et je reste
convaincu que ce type de polémique ne relève ni plus ni moins que de cette
espèce de syndrome décidement très (trop) répandu dans le milieu
Informatique (et Technique) : le désir de pisser plus loin, voir d'en faire
la démonstration face au vent et sans mouiller son pantalon, histoire de
bien marquer sa différence avec son voisin.

Perso, en clair et sans décodeur

1 - on s'en tappe,
2 - s'il est question de développement dans les règles de l'art, il y a des
règles et principes bien plus importants à respecter en priorité, que de
polémiquer sur echo ou print,
3 - décidement, l'Informatique manque de fille !

Armel.

Bonjour,

Certes il existe des différences entre les 2 fonctions, mais
tellement minimes qu'on ne voit pas pourquoi modifier tout son code.

Je confirme à nouveau :)

Perso je n'ai rien appris de fondamentalement nouveau sur les différences
profondes entre echo et print, m'enfin peu importe. L'exposé de KDO en aura
probablement éclairé certain. Et c'est tant mieux. Maintenant, quant à la
preuve par les mesures effectuées par KDO, j'y reste peu senssible : 90.5
req/s contre 88.7 req/s. Et puis ? J'irais même plus loin dans la mesure ou
je me suis moi même amusé à rejouer ce bench sur un de mes serveurs, dans
les conditions proposées par KDO (stress via Apache Bench, 1000 requêtes,
etc.). Voici ce que j'observe :

Serveur P4 @ 1.8 Ghz / Linux 2.4.18 / PHP 4.3.4

echo.php : 174.03 req/s
print.php : 174.70 req/s
echo.php : 182.48 req/s
print.php : 180.28 req/s
echo.php : 169.84 req/s
print.php : 175.01 req/s
...and so on.

Je me suis également amusé à mesurer tout cela différement. L'idée était
d'attaquer les scripts en CGI pure et de mesurer les temps via la commande
time (d'Unix). Je me détache donc totalement du Web. Il n'est plus question
ici d'attaquer un serveur en HTTP et de mesurer les temps via Apache Bench.
Ca donne quoi :

#! /bin/sh
for (( i=1; i<P0; i++ ))
do
php -q $1
done
---------
time ./bench.sh echo.php > echo.log

real 0m40.924s
user 0m33.480s
sys 0m7.350s
---------
time ./bench.sh print.php > print.log

real 0m41.182s
user 0m33.490s
sys 0m7.250s
---------
time ./bench.sh echo.php > echo.log

real 0m41.138s
user 0m33.630s
sys 0m7.280s
---------
time ./bench.sh print.php > print.log

real 0m41.061s
user 0m33.390s
sys 0m7.440s
---------
...and so on again !

Je pourrais continuer et rejouer ces benchs indéfiniement, cela ne
changerait rien.

J'en conclu quoi ? Loin de moi l'idée de remettre en cause le fait que,
techniquement, echo ne peut-être que plus rapide que print. Je ne le
contesterais pas. Et sur un jeu large de test large, les mesures tendent à
le montrer. C'est rassurant, parceque c'est logique. Donc tant mieux :)

Maintenant, on remarquera que les différences observées sont clairement du
domaine de la curiosité. Tant sur la première série de bench, que sur la
seconde, il arrive même que les conditions soient plus favorables à print
que à echo. Et pour cause. D'une part les mesures sont fatalement perturbées
par l'environement et le contexte. Il suffit qu'un sync au niveau
filesystem, ou tout autre intervention prioritaire, interviennent pendant
une série de mesure pour en changer les résultats, c'est évidement. Et
personne ne s'en étonnera. D'autre part, l'idée même de mesurer des choses
aussi atomiques n'a pas réellement de sens. Et c'est surtout très éloigné de
conditions réelles, j'entends, en production. Enfin, si ma formation
scientifique m'a bien enseigné quelque chose, c'est bien le fait qu'en terme
de mesure, il convient toujours d'être prudent. J'aurais ainsi tendance à
concidérer que les différences observées sont plus expliquable par les
erreurs de mesures, que par autre chose. Comparer 0m41.138s et 0m41.061s
suggère de souligner un écart de...77 ms. Je m'amuse :)

Bref, bref, loin de moi l'idée de polémiquer autour de tout ceci. Sans
compter que, en ce qui me concerne et comme le rappelais Pimousse, je
m'étais effectivement déjà exprimé sur le sujet. Mais force est de constater
que, 2 ans plus tard, je confirme à nouveau la chose :) Et je reste
convaincu que ce type de polémique ne relève ni plus ni moins que de cette
espèce de syndrome décidement très (trop) répandu dans le milieu
Informatique (et Technique) : le désir de pisser plus loin, voir d'en faire
la démonstration face au vent et sans mouiller son pantalon, histoire de
bien marquer sa différence avec son voisin.

Perso, en clair et sans décodeur

1 - on s'en tappe,
2 - s'il est question de développement dans les règles de l'art, il y a des
règles et principes bien plus importants à respecter en priorité, que de
polémiquer sur echo ou print,
3 - décidement, l'Informatique manque de fille !

Armel.

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Certes il existe des différences entre les 2 fonctions, mais
tellement minimes qu'on ne voit pas pourquoi modifier tout son code.

Je confirme à nouveau :)

Perso je n'ai rien appris de fondamentalement nouveau sur les différences
profondes entre echo et print, m'enfin peu importe. L'exposé de KDO en aura
probablement éclairé certain. Et c'est tant mieux. Maintenant, quant à la
preuve par les mesures effectuées par KDO, j'y reste peu senssible : 90.5
req/s contre 88.7 req/s. Et puis ? J'irais même plus loin dans la mesure ou
je me suis moi même amusé à rejouer ce bench sur un de mes serveurs, dans
les conditions proposées par KDO (stress via Apache Bench, 1000 requêtes,
etc.). Voici ce que j'observe :

Serveur P4 @ 1.8 Ghz / Linux 2.4.18 / PHP 4.3.4

echo.php : 174.03 req/s
print.php : 174.70 req/s
echo.php : 182.48 req/s
print.php : 180.28 req/s
echo.php : 169.84 req/s
print.php : 175.01 req/s
...and so on.

Je me suis également amusé à mesurer tout cela différement. L'idée était
d'attaquer les scripts en CGI pure et de mesurer les temps via la commande
time (d'Unix). Je me détache donc totalement du Web. Il n'est plus question
ici d'attaquer un serveur en HTTP et de mesurer les temps via Apache Bench.
Ca donne quoi :

#! /bin/sh
for (( i=1; i<P0; i++ ))
do
php -q $1
done
---------
time ./bench.sh echo.php > echo.log

real 0m40.924s
user 0m33.480s
sys 0m7.350s
---------
time ./bench.sh print.php > print.log

real 0m41.182s
user 0m33.490s
sys 0m7.250s
---------
time ./bench.sh echo.php > echo.log

real 0m41.138s
user 0m33.630s
sys 0m7.280s
---------
time ./bench.sh print.php > print.log

real 0m41.061s
user 0m33.390s
sys 0m7.440s
---------
...and so on again !

Je pourrais continuer et rejouer ces benchs indéfiniement, cela ne
changerait rien.

J'en conclu quoi ? Loin de moi l'idée de remettre en cause le fait que,
techniquement, echo ne peut-être que plus rapide que print. Je ne le
contesterais pas. Et sur un jeu large de test large, les mesures tendent à
le montrer. C'est rassurant, parceque c'est logique. Donc tant mieux :)

Maintenant, on remarquera que les différences observées sont clairement du
domaine de la curiosité. Tant sur la première série de bench, que sur la
seconde, il arrive même que les conditions soient plus favorables à print
que à echo. Et pour cause. D'une part les mesures sont fatalement perturbées
par l'environement et le contexte. Il suffit qu'un sync au niveau
filesystem, ou tout autre intervention prioritaire, interviennent pendant
une série de mesure pour en changer les résultats, c'est évidement. Et
personne ne s'en étonnera. D'autre part, l'idée même de mesurer des choses
aussi atomiques n'a pas réellement de sens. Et c'est surtout très éloigné de
conditions réelles, j'entends, en production. Enfin, si ma formation
scientifique m'a bien enseigné quelque chose, c'est bien le fait qu'en terme
de mesure, il convient toujours d'être prudent. J'aurais ainsi tendance à
concidérer que les différences observées sont plus expliquable par les
erreurs de mesures, que par autre chose. Comparer 0m41.138s et 0m41.061s
suggère de souligner un écart de...77 ms. Je m'amuse :)

Bref, bref, loin de moi l'idée de polémiquer autour de tout ceci. Sans
compter que, en ce qui me concerne et comme le rappelais Pimousse, je
m'étais effectivement déjà exprimé sur le sujet. Mais force est de constater
que, 2 ans plus tard, je confirme à nouveau la chose :) Et je reste
convaincu que ce type de polémique ne relève ni plus ni moins que de cette
espèce de syndrome décidement très (trop) répandu dans le milieu
Informatique (et Technique) : le désir de pisser plus loin, voir d'en faire
la démonstration face au vent et sans mouiller son pantalon, histoire de
bien marquer sa différence avec son voisin.

Perso, en clair et sans décodeur

1 - on s'en tappe,
2 - s'il est question de développement dans les règles de l'art, il y a des
règles et principes bien plus importants à respecter en priorité, que de
polémiquer sur echo ou print,
3 - décidement, l'Informatique manque de fille !

Armel.

Pimousse

12/05/2004 à 18:04

3 - décidement, l'Informatique manque de fille !

c'est en effet ce qu'on doit retenir ;) !
2 filles pour 25 mecs en option info cette année, c'est pas comme ça
qu'on va inverser la tendance !

tyoup

12/05/2004 à 20:07

Pimousse wrote:

3 - décidement, l'Informatique manque de fille !

c'est en effet ce qu'on doit retenir ;) !
2 filles pour 25 mecs en option info cette année, c'est pas comme ça
qu'on va inverser la tendance !

c'est universel 12 %

=)

n'empèche que dans les 12% ... enfin bref

--
tyoup

John Gallet

12/05/2004 à 20:07

Bonsoir,

fichiers section_1.php, section_2.php etc, etc.

C'est quoi une section ?

Elles incluent toutes
les fichiers suivant (afin d'avoir une application homogène) :
* header.php
* foot.php
* config.php
* lang.php
1. Serait-il plus performant de faire un fichier "appli.php" intégrant
TOUTE l'application et gérant l'appel aux différentes fonctionnalités ou
le fonctionnement en "éxécutables distincts" est-il plus performant ?

Tu mets en concurrence le temps entre parser un seul fichier et utiliser
des inclure/require(once). Donc compte le nombre de fois qu'ils
apparaissent et tu sauras si c'est rentable. Sachant qu'il vaut mieux
faire un include('toto.php'); exit() qu'un
header(Location:toto.php?args) évidemment...

2. Il y a une base MySQL stockant les données dans une dizaine de tables
avec un nombre d'enregistrements variable, d'une dizaine à quelques
centaines (200, 300 peut-être). Etant donné que chaque section fait appel
aux données de différentes tables (entre 2 et 5 requêtes SQL par page),
j'envisageais de stocker le contenu de
la base dans les variables de session. Est-ce raisonnable et intéressant
au niveau rapidité d'exécution ?

Est-ce que ton application se prête à la notion de cache ?

Prenons une même personne qui navigue sur 10 pages d'affilée. Si au
cours de ces 10 requêtes tu fais 5 fois la **même** requête alors tu
peux remplacer [5 connexions SGBD + 5 requêtes] par [1 connexion +
1requête + 4 accès disque]. Est-ce que l'accès disque des sessions sera
plus rapide que la connexion sur la même machine et la lecture du disque
par mysql ? Probablement, mais de combien ? Difficile à dire, surtout
que les bases de données ont elles-même un cache mémoire des requêtes
récentes (totalement transparent).

Ceci est-il même possible ? Est-ce que pendant les 10 minutes de
navigation de cette personne 1 il ne peut pas y avoir une personne 2 aui
modifie les données ramenées par cette requête et mises en session cas
dans lequel on va afficher des données fausses ? (alors que faire la
requête garanti que la donnée sera valide).

3. Par ailleurs j'envisage de "remplacer" le stockage MySQL par des
fichiers XML. Les performances seront-elles équivalentes (ou au moins pas
pires) ? Vaut-il mieux stocker les données dans différents fichiers (un
XML par table, a priori, je compte garder l'aspect "base de données
relationnelle" dans un premier temps) ou un unique fichier XML
représentant ma base de données actuelle ?

Je te fais la version courte. Si tu veux la version longue, dis le moi,
je développerai. XML, c'est du fichier plat. Vaguement hierarchisé, mais
c'est du fichier plat. Si tu veux avoir accès à un noeud bien précis, tu
vas faire de l'accès séquentiel. Or, ça fait plus de 20 ans que des
braves gens s'emmerdent à écrire des SGBDR pour remplacer les fichiers
plats. Il y a probablement une raison. En particulier, la gestion de
l'intégrité des données par des contraintes de type UNIQUE / PRIMARY /
FOREIGN.

Je précise que la disponibilité du serveur n'est pas critique (en
l'occurence ça tourne en local sur mon PC) mais bon, autant faire les
choses le mieux possible.

"le mieux" ne se limite certainement pas aux performances pures. Si tu
as des données corrompues, les donner à l'utilisateur à la vitesse de
l'éclair ne changera pas le fait que tu lui fournis de la merde...

Quand dans 6 mois toi ou quelqu'un d'autre va reprendre le code pour
faire une modification mineure, s'il doit commencer par passer deux
heures à comprendre / se souvenir de comment marche le biniou tout ça
pour gagner (on espère...) 20millisecondes à l'exécution de chaque
requête, ce n'est PAS une économie pour l'entreprise.

Un bon code n'est pas un code qui est seulement ultra rapide à
l'exécution. Du moment que les performances sont acceptables en montée
en charge, les performances ne sont PAS le but premier d'un code correct
(dans une optique de coûts pour l'entreprise). J'ai pas dit qu'il faut
écrire n'importe quoi, mais qu'il faut mettre en balance le temps passé
à gagner trois pouillèmes par rapport à celui passé à documenter
correctement, réfléchir à la conception pour éviter les erreurs
majeures, etc...

a++
JG

Bonsoir,

fichiers section_1.php, section_2.php etc, etc.

C'est quoi une section ?

Elles incluent toutes
les fichiers suivant (afin d'avoir une application homogène) :
* header.php
* foot.php
* config.php
* lang.php
1. Serait-il plus performant de faire un fichier "appli.php" intégrant
TOUTE l'application et gérant l'appel aux différentes fonctionnalités ou
le fonctionnement en "éxécutables distincts" est-il plus performant ?

Tu mets en concurrence le temps entre parser un seul fichier et utiliser
des inclure/require(once). Donc compte le nombre de fois qu'ils
apparaissent et tu sauras si c'est rentable. Sachant qu'il vaut mieux
faire un include('toto.php'); exit() qu'un
header(Location:toto.php?args) évidemment...

2. Il y a une base MySQL stockant les données dans une dizaine de tables
avec un nombre d'enregistrements variable, d'une dizaine à quelques
centaines (200, 300 peut-être). Etant donné que chaque section fait appel
aux données de différentes tables (entre 2 et 5 requêtes SQL par page),
j'envisageais de stocker le contenu de
la base dans les variables de session. Est-ce raisonnable et intéressant
au niveau rapidité d'exécution ?

Est-ce que ton application se prête à la notion de cache ?

Prenons une même personne qui navigue sur 10 pages d'affilée. Si au
cours de ces 10 requêtes tu fais 5 fois la **même** requête alors tu
peux remplacer [5 connexions SGBD + 5 requêtes] par [1 connexion +
1requête + 4 accès disque]. Est-ce que l'accès disque des sessions sera
plus rapide que la connexion sur la même machine et la lecture du disque
par mysql ? Probablement, mais de combien ? Difficile à dire, surtout
que les bases de données ont elles-même un cache mémoire des requêtes
récentes (totalement transparent).

Ceci est-il même possible ? Est-ce que pendant les 10 minutes de
navigation de cette personne 1 il ne peut pas y avoir une personne 2 aui
modifie les données ramenées par cette requête et mises en session cas
dans lequel on va afficher des données fausses ? (alors que faire la
requête garanti que la donnée sera valide).

3. Par ailleurs j'envisage de "remplacer" le stockage MySQL par des
fichiers XML. Les performances seront-elles équivalentes (ou au moins pas
pires) ? Vaut-il mieux stocker les données dans différents fichiers (un
XML par table, a priori, je compte garder l'aspect "base de données
relationnelle" dans un premier temps) ou un unique fichier XML
représentant ma base de données actuelle ?

Je te fais la version courte. Si tu veux la version longue, dis le moi,
je développerai. XML, c'est du fichier plat. Vaguement hierarchisé, mais
c'est du fichier plat. Si tu veux avoir accès à un noeud bien précis, tu
vas faire de l'accès séquentiel. Or, ça fait plus de 20 ans que des
braves gens s'emmerdent à écrire des SGBDR pour remplacer les fichiers
plats. Il y a probablement une raison. En particulier, la gestion de
l'intégrité des données par des contraintes de type UNIQUE / PRIMARY /
FOREIGN.

Je précise que la disponibilité du serveur n'est pas critique (en
l'occurence ça tourne en local sur mon PC) mais bon, autant faire les
choses le mieux possible.

"le mieux" ne se limite certainement pas aux performances pures. Si tu
as des données corrompues, les donner à l'utilisateur à la vitesse de
l'éclair ne changera pas le fait que tu lui fournis de la merde...

Quand dans 6 mois toi ou quelqu'un d'autre va reprendre le code pour
faire une modification mineure, s'il doit commencer par passer deux
heures à comprendre / se souvenir de comment marche le biniou tout ça
pour gagner (on espère...) 20millisecondes à l'exécution de chaque
requête, ce n'est PAS une économie pour l'entreprise.

Un bon code n'est pas un code qui est seulement ultra rapide à
l'exécution. Du moment que les performances sont acceptables en montée
en charge, les performances ne sont PAS le but premier d'un code correct
(dans une optique de coûts pour l'entreprise). J'ai pas dit qu'il faut
écrire n'importe quoi, mais qu'il faut mettre en balance le temps passé
à gagner trois pouillèmes par rapport à celui passé à documenter
correctement, réfléchir à la conception pour éviter les erreurs
majeures, etc...

a++
JG

Vous avez filtré cet utilisateur ! Consultez son message

Bonsoir,

fichiers section_1.php, section_2.php etc, etc.

C'est quoi une section ?

Elles incluent toutes
les fichiers suivant (afin d'avoir une application homogène) :
* header.php
* foot.php
* config.php
* lang.php
1. Serait-il plus performant de faire un fichier "appli.php" intégrant
TOUTE l'application et gérant l'appel aux différentes fonctionnalités ou
le fonctionnement en "éxécutables distincts" est-il plus performant ?

Tu mets en concurrence le temps entre parser un seul fichier et utiliser
des inclure/require(once). Donc compte le nombre de fois qu'ils
apparaissent et tu sauras si c'est rentable. Sachant qu'il vaut mieux
faire un include('toto.php'); exit() qu'un
header(Location:toto.php?args) évidemment...

2. Il y a une base MySQL stockant les données dans une dizaine de tables
avec un nombre d'enregistrements variable, d'une dizaine à quelques
centaines (200, 300 peut-être). Etant donné que chaque section fait appel
aux données de différentes tables (entre 2 et 5 requêtes SQL par page),
j'envisageais de stocker le contenu de
la base dans les variables de session. Est-ce raisonnable et intéressant
au niveau rapidité d'exécution ?

Est-ce que ton application se prête à la notion de cache ?

Prenons une même personne qui navigue sur 10 pages d'affilée. Si au
cours de ces 10 requêtes tu fais 5 fois la **même** requête alors tu
peux remplacer [5 connexions SGBD + 5 requêtes] par [1 connexion +
1requête + 4 accès disque]. Est-ce que l'accès disque des sessions sera
plus rapide que la connexion sur la même machine et la lecture du disque
par mysql ? Probablement, mais de combien ? Difficile à dire, surtout
que les bases de données ont elles-même un cache mémoire des requêtes
récentes (totalement transparent).

Ceci est-il même possible ? Est-ce que pendant les 10 minutes de
navigation de cette personne 1 il ne peut pas y avoir une personne 2 aui
modifie les données ramenées par cette requête et mises en session cas
dans lequel on va afficher des données fausses ? (alors que faire la
requête garanti que la donnée sera valide).

3. Par ailleurs j'envisage de "remplacer" le stockage MySQL par des
fichiers XML. Les performances seront-elles équivalentes (ou au moins pas
pires) ? Vaut-il mieux stocker les données dans différents fichiers (un
XML par table, a priori, je compte garder l'aspect "base de données
relationnelle" dans un premier temps) ou un unique fichier XML
représentant ma base de données actuelle ?

Je te fais la version courte. Si tu veux la version longue, dis le moi,
je développerai. XML, c'est du fichier plat. Vaguement hierarchisé, mais
c'est du fichier plat. Si tu veux avoir accès à un noeud bien précis, tu
vas faire de l'accès séquentiel. Or, ça fait plus de 20 ans que des
braves gens s'emmerdent à écrire des SGBDR pour remplacer les fichiers
plats. Il y a probablement une raison. En particulier, la gestion de
l'intégrité des données par des contraintes de type UNIQUE / PRIMARY /
FOREIGN.

Je précise que la disponibilité du serveur n'est pas critique (en
l'occurence ça tourne en local sur mon PC) mais bon, autant faire les
choses le mieux possible.

"le mieux" ne se limite certainement pas aux performances pures. Si tu
as des données corrompues, les donner à l'utilisateur à la vitesse de
l'éclair ne changera pas le fait que tu lui fournis de la merde...

Quand dans 6 mois toi ou quelqu'un d'autre va reprendre le code pour
faire une modification mineure, s'il doit commencer par passer deux
heures à comprendre / se souvenir de comment marche le biniou tout ça
pour gagner (on espère...) 20millisecondes à l'exécution de chaque
requête, ce n'est PAS une économie pour l'entreprise.

Un bon code n'est pas un code qui est seulement ultra rapide à
l'exécution. Du moment que les performances sont acceptables en montée
en charge, les performances ne sont PAS le but premier d'un code correct
(dans une optique de coûts pour l'entreprise). J'ai pas dit qu'il faut
écrire n'importe quoi, mais qu'il faut mettre en balance le temps passé
à gagner trois pouillèmes par rapport à celui passé à documenter
correctement, réfléchir à la conception pour éviter les erreurs
majeures, etc...

a++
JG

loufoque

12/05/2004 à 20:41

John Gallet wrote:

Prenons une même personne qui navigue sur 10 pages d'affilée. Si au
cours de ces 10 requêtes tu fais 5 fois la **même** requête alors tu
peux remplacer [5 connexions SGBD + 5 requêtes] par [1 connexion +
1requête + 4 accès disque]. Est-ce que l'accès disque des sessions sera
plus rapide que la connexion sur la même machine et la lecture du disque
par mysql ? Probablement, mais de combien ? Difficile à dire, surtout
que les bases de données ont elles-même un cache mémoire des requêtes
récentes (totalement transparent).

L'utilité du cache disque, c'est justement de diminuer les connexions.
Sur des serveurs mutualisés, le nombre de connexions simultanées à une
base MySQL est souvent limité par exemple.

RAKOTOMALALA Renaud

12/05/2004 à 21:42

Genre préférer utiliser 1 requète SQL comportant des "left join" plutot
que 3 requetes sql.
de toutes manières, je suis anti-print parce que ça me rappelle trop mes
débuts en basic (vous avez connu les ZX81 et les MSX?)

Tout dépend du SGDB(R) si celà est vrai pour les SGDB relationnel
evolué, ça ne l'etait pas pour MySQL du moins en version 3.x me emble t
il ou justement il est preferable de ne pas utiliser les jointures mais
plutot des requetes imbriqués.

Ce que n'a pas dit l'auteur original, c'est que echo et print même si
ces deux pseudos fonctions ont des resultats similaires les programmeurs
de C (entre autre) veront tout de suite une chose qui saute aux yeux:

Prototype: int print ( string arg)
Prototype: void echo ( string arg1 [, string argn...])

dans le premier cas nous avons une fonction qui renvoi un INT alors que
la deuxième est de type void ce qui signifie qu'elle ne retourne rien.

Il est donc tout de suite logique sans aller au delà de l'appel de la
fonction de comprendre que puisque print retourne une valeur entière
alors que echo non cette dernière s'executera fondamentalement plus
rapidement.

Celà dit echo et print ne s'utiliseront donc pas de la même manière.

Cordialement,
--
RAKOTOMALALA RENAUD
W-CONSULTING http://www.w-consulting.fr
Librenet Network http://www.librenet.net
InsideNetworks http://www.insidenetworks.net

PRINT vs ECHO

10 réponses

Veuillez sélectionner un problème