PRINT vs ECHO

Sam

12/05/2004 à 10:26

La même chose sans attaque personnelle, ça aurait été super...
ça reste néammoins intéressant. Merci.

"KDO" a écrit

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

Pimousse

12/05/2004 à 10:26

Bonjour,

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

Comme d'habitude, on remarquera tous le langage chatié utilisé par KDO
(Loquace ?), aussi bien sur le post que dans son article. Finesse lycéenne ?

Pour te répondre, et dans la lignée de ce que j'avais lu de toi, je vais
citer le post d'Armel, sur ce forum, datant du 08 Mars 2002 :

------
Tu fais bien de souligner la chose en disant "optimisation bete" :)
Parce que sérieux, la problématique du "echo vs print" est vraiment
limite stupide :)
Posons nous 5 minutes. Si sur 1 million d'echo ou de print, on économise
entre 15 et 30 ms de CPU, cela veut dire qu'un *gros* site faisant par
exemple 10 millions de pages vues / mois et qui comporterait par exemple 10
echo/print en moyenne par page...ferait l'économie de...1 demi poil de cul
:)

Bref, avant de faire un massif recherche/remplace récursif dans vos applis
pour basculer de l'un à l'autre, il y a certainement (bcp) d'autres chose à
améliorer en priorité. Enfin, je crois :)

Ceci étant, "print vs echo" étant un véritable maronier depuis que PHP
existe, on a pas fini dans parler dans les chaumières :) Ca peut occuper les
jours de pluie :p

Armel.
------

Je pense exactement comme lui. C'est ce qu'on avait essayé de te faire
comprendre. Certes il existe des différences entre les 2 fonctions, mais
tellement minimes qu'on ne voit pas pourquoi modifier tout son code.

Désolé pour toi.
Et sache que tu ne convaincras jamais personne en étant grossier et
agressif : par contre, vous vous mettrez peut être sur la gueule un jour
....

@++
Pimousse

CrazyCat

12/05/2004 à 10:26

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

Heu, bel article mais pas dédié au neu² (j'en suis un, je sais de quoi
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?
--
Tout sur les eggdrops
http://www.c-p-f.org
ML @

John Gallet

12/05/2004 à 10:46

'alut,

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

Pour les trois premiers qualificatifs, j'assume sans problème, surtout
si c'est toi qui le dit :-)

Pour ceux qui n'ont pas le temps de lire, je résume ma position qui est
la même depuis fin 1999 sur ce forum et son ancêtre : quand on aura plus
que ça à optimiser dans les scripts php qui tournent, on en reparlera :
le gain est négligeable par rapport au temps perdu dans des empilements
successifs de couches inutiles et des algorithmes bancals (bancaux ?).

En revanche loin de moi l'idée de faire du perl, j'en ai jamais écrit
une ligne de ma vie. Mes premiers scripts php fin 1999 étaient une
adaptation d'un ensemble de scripts shell et awk. Les echo du shell sont
restés des echo en php, les print du awk sont probablement restés print
eux aussi. Si je retrouve les scripts en question sur un vieux disque
dur, je ferai un find -exec grep à l'occasion.

Je passe sur ta description du fonctionnement interne du moteur, qui m'a
intéressée mais là n'est pas le sujet.

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.
Le rÃ©sultat est conforme Ã ce qui est prÃ©vu:

Et qui était cité dans le lien donné dans le thread auquel tu fais
référence : Dixit Rasmus lui même "echo is marginally faster".
Marginally : un tout petit peu.

en moyenne le script 'echo' permet
d'effectuer 90.5 req/s contre 88.7 req/s pour le 'print'.
Ok.

Une diffÃ©rence certes 'nÃ©gligeable'
Amen.

**Donc** nous sommes bien d'accord : utiliser echo ou print on s'en bat
les couilles pour le résultat. C'est tout ce que je disais. On peut
ensuite débattre sur le fond.

Bref pour rester dans le non-politiKement-Korrekt qui me caractÃ©rise, je dirai que
l'usage du 'print' et de 'echo' dÃ©finit la frontiÃ¨re entre les porcs et les
artisans du code ...

Nous sommes bien d'accord sur le fond : les porcs utilisent print, les
artisans amateurs utilisent echo. Dans les deux cas, c'est de
l'utilisation bête et méchante sur laquelle il n'y a RIEN à gagner par
rapport à toutes les conneries présentes dans les scripts qui sont des
erreurs de logique et des traitements sous optimaux (trois requêtes SQL
là où une seule suffit), pas de break / continue dans des traitements en
boucle alors qu'on sait que le cas ne peut plus se produire, sélections
de population de données inutiles, modèles de bases de données non
dénormalisés et nécessitant 5 jointures pour accéder à la moindre donnée
utile etc...

Alors me direz vous, tout cela pour si peu ? Oui, parce que l'attitude de J.Gallet
montre que le manque de rigueur dans l'utilisation de ces 2 instructions ne
peut prÃ©sager que du mÃªme comportement dans le reste de l'utilisation de PHP :
regex au lieu de 'strstr' par exemple

Elle ne peut **que** présager.

Parce que si tu me demandes quoi utiser entre regexp et str je te
répondrais sans hésiter "pas regexp". Parce ***là*** c'est pas
négligeable et loin de là. Il y a longtemps que des benchs sont faits
sur toutes ces fonctions.

Une autre tarte à la crème c'est l'utilisation de :

echo "CONSTANTE $machin"; par rapport à echo 'CONSTANTE '.$machin;

**OUI** il y en a un (de mémoire le second ?) qui permet de gagner trois
poils de cul par rapport au premier. Mais par rapport à tout le temps
perdu parce que l'algorithmique du script est totalement sous optimale,
c'est pas là que les problèmes de performances vont être résolus.

Ne confondons pas tout. Quand j'affirme qu'on en a rien à foutre
d'utiliser echo ou print c'est en connaissance de cause et argumenté
parce que le gain est **négligeable par rapport aux améliorations à
faire**. Mais je dirais pas la même chose pour tout.

Quand tu dis qu'on pourrait gagner 20% à 30 % de perfs simplement en
rendant PHP case insensitive pour les fonctions (ça fait deux ans que tu
en parles), là je dis OUI et trois fois OUI (surtout que c'est cité
comme point faible dans un comparatif entre php et asp chez Oracle). Là
ce ne sont pas des économies de bouts de chandelle.

Au fait John, dÃ©solÃ© mais cette page est valide html4/strict, j'espÃ¨re que malgrÃ© tout
elle devrait passer sur ton Netscape 4.7 ;)

Modulo le charset et le fond gris, oui, elle passe :-)

En revanche un point que je ne suis pas certain d'avoir compris dans ton
article :

ou utilisation systÃ©matique des " derriÃ¨re un print/echo

C'est à dire ? Ecrire par exemple echo "$toto"; au lieu de echo $toto; ?
Là aussi on frise l'économie de bouts de chandelles, **par rapport** à
tout le temps perdu dans les couches successives de Pear ;-)

a++
John

'alut,

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

Pour les trois premiers qualificatifs, j'assume sans problème, surtout
si c'est toi qui le dit :-)

Pour ceux qui n'ont pas le temps de lire, je résume ma position qui est
la même depuis fin 1999 sur ce forum et son ancêtre : quand on aura plus
que ça à optimiser dans les scripts php qui tournent, on en reparlera :
le gain est négligeable par rapport au temps perdu dans des empilements
successifs de couches inutiles et des algorithmes bancals (bancaux ?).

En revanche loin de moi l'idée de faire du perl, j'en ai jamais écrit
une ligne de ma vie. Mes premiers scripts php fin 1999 étaient une
adaptation d'un ensemble de scripts shell et awk. Les echo du shell sont
restés des echo en php, les print du awk sont probablement restés print
eux aussi. Si je retrouve les scripts en question sur un vieux disque
dur, je ferai un find -exec grep à l'occasion.

Je passe sur ta description du fonctionnement interne du moteur, qui m'a
intéressée mais là n'est pas le sujet.

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.
Le rÃ©sultat est conforme Ã ce qui est prÃ©vu:

Et qui était cité dans le lien donné dans le thread auquel tu fais
référence : Dixit Rasmus lui même "echo is marginally faster".
Marginally : un tout petit peu.

en moyenne le script 'echo' permet
d'effectuer 90.5 req/s contre 88.7 req/s pour le 'print'.
Ok.

Une diffÃ©rence certes 'nÃ©gligeable'
Amen.

**Donc** nous sommes bien d'accord : utiliser echo ou print on s'en bat
les couilles pour le résultat. C'est tout ce que je disais. On peut
ensuite débattre sur le fond.

Bref pour rester dans le non-politiKement-Korrekt qui me caractÃ©rise, je dirai que
l'usage du 'print' et de 'echo' dÃ©finit la frontiÃ¨re entre les porcs et les
artisans du code ...

Nous sommes bien d'accord sur le fond : les porcs utilisent print, les
artisans amateurs utilisent echo. Dans les deux cas, c'est de
l'utilisation bête et méchante sur laquelle il n'y a RIEN à gagner par
rapport à toutes les conneries présentes dans les scripts qui sont des
erreurs de logique et des traitements sous optimaux (trois requêtes SQL
là où une seule suffit), pas de break / continue dans des traitements en
boucle alors qu'on sait que le cas ne peut plus se produire, sélections
de population de données inutiles, modèles de bases de données non
dénormalisés et nécessitant 5 jointures pour accéder à la moindre donnée
utile etc...

Alors me direz vous, tout cela pour si peu ? Oui, parce que l'attitude de J.Gallet
montre que le manque de rigueur dans l'utilisation de ces 2 instructions ne
peut prÃ©sager que du mÃªme comportement dans le reste de l'utilisation de PHP :
regex au lieu de 'strstr' par exemple

Elle ne peut **que** présager.

Parce que si tu me demandes quoi utiser entre regexp et str je te
répondrais sans hésiter "pas regexp". Parce ***là*** c'est pas
négligeable et loin de là. Il y a longtemps que des benchs sont faits
sur toutes ces fonctions.

Une autre tarte à la crème c'est l'utilisation de :

echo "CONSTANTE $machin"; par rapport à echo 'CONSTANTE '.$machin;

**OUI** il y en a un (de mémoire le second ?) qui permet de gagner trois
poils de cul par rapport au premier. Mais par rapport à tout le temps
perdu parce que l'algorithmique du script est totalement sous optimale,
c'est pas là que les problèmes de performances vont être résolus.

Ne confondons pas tout. Quand j'affirme qu'on en a rien à foutre
d'utiliser echo ou print c'est en connaissance de cause et argumenté
parce que le gain est **négligeable par rapport aux améliorations à
faire**. Mais je dirais pas la même chose pour tout.

Quand tu dis qu'on pourrait gagner 20% à 30 % de perfs simplement en
rendant PHP case insensitive pour les fonctions (ça fait deux ans que tu
en parles), là je dis OUI et trois fois OUI (surtout que c'est cité
comme point faible dans un comparatif entre php et asp chez Oracle). Là
ce ne sont pas des économies de bouts de chandelle.

Au fait John, dÃ©solÃ© mais cette page est valide html4/strict, j'espÃ¨re que malgrÃ© tout
elle devrait passer sur ton Netscape 4.7 ;)

Modulo le charset et le fond gris, oui, elle passe :-)

En revanche un point que je ne suis pas certain d'avoir compris dans ton
article :

ou utilisation systÃ©matique des " derriÃ¨re un print/echo

C'est à dire ? Ecrire par exemple echo "$toto"; au lieu de echo $toto; ?
Là aussi on frise l'économie de bouts de chandelles, **par rapport** à
tout le temps perdu dans les couches successives de Pear ;-)

a++
John

Vous avez filtré cet utilisateur ! Consultez son message

'alut,

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

Pour les trois premiers qualificatifs, j'assume sans problème, surtout
si c'est toi qui le dit :-)

Pour ceux qui n'ont pas le temps de lire, je résume ma position qui est
la même depuis fin 1999 sur ce forum et son ancêtre : quand on aura plus
que ça à optimiser dans les scripts php qui tournent, on en reparlera :
le gain est négligeable par rapport au temps perdu dans des empilements
successifs de couches inutiles et des algorithmes bancals (bancaux ?).

En revanche loin de moi l'idée de faire du perl, j'en ai jamais écrit
une ligne de ma vie. Mes premiers scripts php fin 1999 étaient une
adaptation d'un ensemble de scripts shell et awk. Les echo du shell sont
restés des echo en php, les print du awk sont probablement restés print
eux aussi. Si je retrouve les scripts en question sur un vieux disque
dur, je ferai un find -exec grep à l'occasion.

Je passe sur ta description du fonctionnement interne du moteur, qui m'a
intéressée mais là n'est pas le sujet.

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.
Le rÃ©sultat est conforme Ã ce qui est prÃ©vu:

Et qui était cité dans le lien donné dans le thread auquel tu fais
référence : Dixit Rasmus lui même "echo is marginally faster".
Marginally : un tout petit peu.

en moyenne le script 'echo' permet
d'effectuer 90.5 req/s contre 88.7 req/s pour le 'print'.
Ok.

Une diffÃ©rence certes 'nÃ©gligeable'
Amen.

**Donc** nous sommes bien d'accord : utiliser echo ou print on s'en bat
les couilles pour le résultat. C'est tout ce que je disais. On peut
ensuite débattre sur le fond.

Bref pour rester dans le non-politiKement-Korrekt qui me caractÃ©rise, je dirai que
l'usage du 'print' et de 'echo' dÃ©finit la frontiÃ¨re entre les porcs et les
artisans du code ...

Nous sommes bien d'accord sur le fond : les porcs utilisent print, les
artisans amateurs utilisent echo. Dans les deux cas, c'est de
l'utilisation bête et méchante sur laquelle il n'y a RIEN à gagner par
rapport à toutes les conneries présentes dans les scripts qui sont des
erreurs de logique et des traitements sous optimaux (trois requêtes SQL
là où une seule suffit), pas de break / continue dans des traitements en
boucle alors qu'on sait que le cas ne peut plus se produire, sélections
de population de données inutiles, modèles de bases de données non
dénormalisés et nécessitant 5 jointures pour accéder à la moindre donnée
utile etc...

Alors me direz vous, tout cela pour si peu ? Oui, parce que l'attitude de J.Gallet
montre que le manque de rigueur dans l'utilisation de ces 2 instructions ne
peut prÃ©sager que du mÃªme comportement dans le reste de l'utilisation de PHP :
regex au lieu de 'strstr' par exemple

Elle ne peut **que** présager.

Parce que si tu me demandes quoi utiser entre regexp et str je te
répondrais sans hésiter "pas regexp". Parce ***là*** c'est pas
négligeable et loin de là. Il y a longtemps que des benchs sont faits
sur toutes ces fonctions.

Une autre tarte à la crème c'est l'utilisation de :

echo "CONSTANTE $machin"; par rapport à echo 'CONSTANTE '.$machin;

**OUI** il y en a un (de mémoire le second ?) qui permet de gagner trois
poils de cul par rapport au premier. Mais par rapport à tout le temps
perdu parce que l'algorithmique du script est totalement sous optimale,
c'est pas là que les problèmes de performances vont être résolus.

Ne confondons pas tout. Quand j'affirme qu'on en a rien à foutre
d'utiliser echo ou print c'est en connaissance de cause et argumenté
parce que le gain est **négligeable par rapport aux améliorations à
faire**. Mais je dirais pas la même chose pour tout.

Quand tu dis qu'on pourrait gagner 20% à 30 % de perfs simplement en
rendant PHP case insensitive pour les fonctions (ça fait deux ans que tu
en parles), là je dis OUI et trois fois OUI (surtout que c'est cité
comme point faible dans un comparatif entre php et asp chez Oracle). Là
ce ne sont pas des économies de bouts de chandelle.

Au fait John, dÃ©solÃ© mais cette page est valide html4/strict, j'espÃ¨re que malgrÃ© tout
elle devrait passer sur ton Netscape 4.7 ;)

Modulo le charset et le fond gris, oui, elle passe :-)

En revanche un point que je ne suis pas certain d'avoir compris dans ton
article :

ou utilisation systÃ©matique des " derriÃ¨re un print/echo

C'est à dire ? Ecrire par exemple echo "$toto"; au lieu de echo $toto; ?
Là aussi on frise l'économie de bouts de chandelles, **par rapport** à
tout le temps perdu dans les couches successives de Pear ;-)

a++
John

Eric Daspet

12/05/2004 à 12:34

Samuel KABAK wrote:

Si c'est la possibilité de mélanger html et code qui te séduit

Là tu es presque en train de l'insulter sans le savoir ;)

PHP n'est pas une religion mais un outil qui doit permettre d'atteindre un
objectif le plus rapidement possible.

Ah ? donc si moi je n'ai pas exactement le même but que toi il faut que
je change d'outil ? calmons nous et ne prenons pas chacun nos objectifs
et nos raisons d'utiliser PHP comme les seules valables.

A moins d'avoir un site qui génèrent plus que 3000 visiteurs par jour vous
n'avez pas besoin d'optimiser et les conseils de KDO valent 0 euros.

Oui, enfin 3000 visiteurs par jour il y a pas mal de monde qui doit les
faire. Avec un petit blog perso et un ou deux billets par semaine je
suis monté à plus de 1000.

Sans forcément aller jusqu'à faire une comparaison echo/print il ne faut
surtout pas dire de se moquer des perfs. Après on se retrouve avec des
phpbb qui font écrouler des serveurs pour 5 utilisateurs qui se courent
après.
Maintenant, si la diff echo/print est une économie de bout de chandelle
(il y a généralement bien plus à gagner en regardant les algos ou la
config) il n'y a pas de mal à le savoir et à s'en servir car le coup est
nul : il n'y a rien à perdre.
Il est clair que modifier les scripts existants ne vaut pas la peine
(mais alors pas du tout du tout), mais prendre l'habitude d'écrire echo
à la place de print (ou l'inverse) ça ne rend pas moins clair, ça n'est
pas plus long, ça n'est pas plus complexe ... que ça serve
significativement ou pas influe relativement peu finalement.

Et si vous avez un site qui génère les 3000 visiteurs par jours et qui est
lent malgré une connexion de 2 Mb/s, malgré le compilateur et malgré la
machine à processeur Xeon (avec beaucoup de GHz, beaucoup de Mo de ram et
disques SATA ou SCSI) alors payez-vous un consultant digne de ce nom.

Ouais, enfin si tu as besoin de ça pour 3000 visiteurs par jour (c'est à
dire en gros 30 secondes de proc chacun) c'est qu'il y a un gros problème ;)
Il y a peut être un intermédiaire ? :) genre justement coder partout
avec les bonnes méthodes, les bonnes habitudes ... et ne pas se moquer
des perfs. Pour certains la machine est là, probablement bloquée par le
coté financier, et jouer sur les perfs des scripts *est* utile (même si
je doute que la différence echo/print soit suffisante à les aider).

--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
(merci de ne laisser de la citation que le principal, et de répondre au
dessous, pas au desssus)

Samuel KABAK wrote:

Si c'est la possibilité de mélanger html et code qui te séduit

Là tu es presque en train de l'insulter sans le savoir ;)

PHP n'est pas une religion mais un outil qui doit permettre d'atteindre un
objectif le plus rapidement possible.

Ah ? donc si moi je n'ai pas exactement le même but que toi il faut que
je change d'outil ? calmons nous et ne prenons pas chacun nos objectifs
et nos raisons d'utiliser PHP comme les seules valables.

A moins d'avoir un site qui génèrent plus que 3000 visiteurs par jour vous
n'avez pas besoin d'optimiser et les conseils de KDO valent 0 euros.

Oui, enfin 3000 visiteurs par jour il y a pas mal de monde qui doit les
faire. Avec un petit blog perso et un ou deux billets par semaine je
suis monté à plus de 1000.

Sans forcément aller jusqu'à faire une comparaison echo/print il ne faut
surtout pas dire de se moquer des perfs. Après on se retrouve avec des
phpbb qui font écrouler des serveurs pour 5 utilisateurs qui se courent
après.
Maintenant, si la diff echo/print est une économie de bout de chandelle
(il y a généralement bien plus à gagner en regardant les algos ou la
config) il n'y a pas de mal à le savoir et à s'en servir car le coup est
nul : il n'y a rien à perdre.
Il est clair que modifier les scripts existants ne vaut pas la peine
(mais alors pas du tout du tout), mais prendre l'habitude d'écrire echo
à la place de print (ou l'inverse) ça ne rend pas moins clair, ça n'est
pas plus long, ça n'est pas plus complexe ... que ça serve
significativement ou pas influe relativement peu finalement.

Et si vous avez un site qui génère les 3000 visiteurs par jours et qui est
lent malgré une connexion de 2 Mb/s, malgré le compilateur et malgré la
machine à processeur Xeon (avec beaucoup de GHz, beaucoup de Mo de ram et
disques SATA ou SCSI) alors payez-vous un consultant digne de ce nom.

Ouais, enfin si tu as besoin de ça pour 3000 visiteurs par jour (c'est à
dire en gros 30 secondes de proc chacun) c'est qu'il y a un gros problème ;)
Il y a peut être un intermédiaire ? :) genre justement coder partout
avec les bonnes méthodes, les bonnes habitudes ... et ne pas se moquer
des perfs. Pour certains la machine est là, probablement bloquée par le
coté financier, et jouer sur les perfs des scripts *est* utile (même si
je doute que la différence echo/print soit suffisante à les aider).

--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
(merci de ne laisser de la citation que le principal, et de répondre au
dessous, pas au desssus)

Vous avez filtré cet utilisateur ! Consultez son message

Samuel KABAK wrote:

Si c'est la possibilité de mélanger html et code qui te séduit

Là tu es presque en train de l'insulter sans le savoir ;)

PHP n'est pas une religion mais un outil qui doit permettre d'atteindre un
objectif le plus rapidement possible.

Ah ? donc si moi je n'ai pas exactement le même but que toi il faut que
je change d'outil ? calmons nous et ne prenons pas chacun nos objectifs
et nos raisons d'utiliser PHP comme les seules valables.

A moins d'avoir un site qui génèrent plus que 3000 visiteurs par jour vous
n'avez pas besoin d'optimiser et les conseils de KDO valent 0 euros.

Oui, enfin 3000 visiteurs par jour il y a pas mal de monde qui doit les
faire. Avec un petit blog perso et un ou deux billets par semaine je
suis monté à plus de 1000.

Sans forcément aller jusqu'à faire une comparaison echo/print il ne faut
surtout pas dire de se moquer des perfs. Après on se retrouve avec des
phpbb qui font écrouler des serveurs pour 5 utilisateurs qui se courent
après.
Maintenant, si la diff echo/print est une économie de bout de chandelle
(il y a généralement bien plus à gagner en regardant les algos ou la
config) il n'y a pas de mal à le savoir et à s'en servir car le coup est
nul : il n'y a rien à perdre.
Il est clair que modifier les scripts existants ne vaut pas la peine
(mais alors pas du tout du tout), mais prendre l'habitude d'écrire echo
à la place de print (ou l'inverse) ça ne rend pas moins clair, ça n'est
pas plus long, ça n'est pas plus complexe ... que ça serve
significativement ou pas influe relativement peu finalement.

Et si vous avez un site qui génère les 3000 visiteurs par jours et qui est
lent malgré une connexion de 2 Mb/s, malgré le compilateur et malgré la
machine à processeur Xeon (avec beaucoup de GHz, beaucoup de Mo de ram et
disques SATA ou SCSI) alors payez-vous un consultant digne de ce nom.

Ouais, enfin si tu as besoin de ça pour 3000 visiteurs par jour (c'est à
dire en gros 30 secondes de proc chacun) c'est qu'il y a un gros problème ;)
Il y a peut être un intermédiaire ? :) genre justement coder partout
avec les bonnes méthodes, les bonnes habitudes ... et ne pas se moquer
des perfs. Pour certains la machine est là, probablement bloquée par le
coté financier, et jouer sur les perfs des scripts *est* utile (même si
je doute que la différence echo/print soit suffisante à les aider).

--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
(merci de ne laisser de la citation que le principal, et de répondre au
dessous, pas au desssus)

Michel BILLAUD

12/05/2004 à 15:04

John Gallet writes:

Quand tu dis qu'on pourrait gagner 20% à 30 % de perfs simplement en
rendant PHP case insensitive pour les fonctions (ça fait deux ans que tu
en parles), là je dis OUI et trois fois OUI (surtout que c'est cité
comme point faible dans un comparatif entre php et asp chez Oracle). Là
ce ne sont pas des économies de bouts de chandelle.

et par rapport à la même chose en Perl ? :-)

MB
--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Michel BILLAUD

12/05/2004 à 15:04

CrazyCat writes:

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

Heu, bel article mais pas dédié au neu² (j'en suis un, je sais de quoi
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?

On se tue à vous le dire

Un seul paramètre pour print, autant qu'on veut pour echo.

On s'évite donc d'introduire des concaténations de chaines
artificielles en écrivant
echo f(x),'+',g(y),'=',h(z);
plutot que
print f(x).'+'.g(y).'='.h(z);

MB (qui vient de l'apprendre)

--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Guillaume Brocker

12/05/2004 à 15:04

KDO wrote:

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

Bravo ! Quel exemple d'humilité pour tout ceux qui fréquentent ce news
group.

Ce n'est pas quelques bouts de grammaire du language et quelques lignes
de code de l'interpréteur qui démontrent quelconque trace d'intelligence.

Avant de tenter une démonstration puérile de son soit-disant savoir sur
une place publique, il convient de se souvenir que tout le monde a été
un moment ou autre un "gland", un "neuneu" et autres noms d'oiseau.

Toutefois, et ce grâce à Google qui archive les news groups, KDO va
pouvoir enfin passer dans la postérité. :)

--
Guillaume Brocker

Pascal (Collectours)

12/05/2004 à 15:43

Michel BILLAUD wrote:

John Gallet writes:
Quand tu dis qu'on pourrait gagner 20% à 30 % de perfs simplement en
rendant PHP case insensitive pour les fonctions (ça fait deux ans que tu
en parles), là je dis OUI et trois fois OUI (surtout que c'est cité
comme point faible dans un comparatif entre php et asp chez Oracle). Là
ce ne sont pas des économies de bouts de chandelle.

et par rapport à la même chose en Perl ? :-)

MB
Trop grop, passera pas ;-))

Pascal

Damien Accorsi

12/05/2004 à 15:43

J'ai développé une application en PHP/MySQL comportant nombre de fichiers.
Grosso modo, il y a une dizaine de classes définies chacune dans un
fichier particulier (histoire de garder tout ça au clair. Les 6
sections principales de l'application ont été intégrées dans des
fichiers section_1.php, section_2.php etc, etc. Elles incluent toutes
les fichiers suivant (afin d'avoir une application homogène) :
* header.php
* foot.php
* config.php
* lang.php

Je me posais les questions suivantes :

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 ?

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 ?

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 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.

Damien

PRINT vs ECHO

10 réponses

Veuillez sélectionner un problème