OVH Cloud OVH Cloud

PRINT vs ECHO

39 réponses
Avatar
KDO
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

10 réponses

1 2 3 4
Avatar
Damien Accorsi
On Wed, 12 May 2004 18:07:05 +0000, John Gallet wrote:

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


C'est quoi une section ?


En fait c'est une application de gestion de recherche de boulot. J'ai
développé des classes (candidature, société, évènement, etc) et une
section c'est l'instance de cette classe que j'ai mise en place. En gros
quand je fais une opération sur une candidature, l'url recherchée est
localhost/candidature.php, quand je gère un évènement, c'est evenement.php
etc.

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


En fait c'est une application "personnelle", dans le sens où un
utilisateur accède à la gestion de sa recherche d'emploi, et lui seul le
fait. Donc c'est du "mono-utilisateur" et donc, à mon avis le cache est
une bonne idée.

Le bon exemple : j'ai développé le code brutalement pour le moment. Donc
quand j'affiche une candidature, je fais une requête pour la candidature +
une pour la société + une pour l'interlocuteur + une pour l'historique +
une pour le type de candidature, etc. Du coup, avec 80 candidatures je
fais 480 requêtes. C'est complètement absurde (mais bon, j'en suis
conscient, j'ai développé vite fait pour avoir quelque chose d'utilisable
rapidement). La première chose que je vais faire, à mon avis, c'est de
faire une image de ma base en mémoire dans des variables PHP. Du coup ça
réduira le nombre de requêtes à dix requêtes environ par page. Etant donné
que les infos sont reprises à chaque page, je pensais faire un cache qui
soit ré-initialisé à chaque modification de la base de données. Mais
compte tenu du nombre d'enregistrements, je ne sais pas si ça vaut le coup
de tout mettre en variable de session (dans mon cas environ 500
enregistrements toutes tables confondues, mais je pense qu'il faut pouvoir
gérer 2000 ou 3000 éléments pour être tranquille).

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


sachant que les données sont "individuelles", il me semble que tabler sur
une unique connexion à la fois est envisageable. C'est à dire qu'on peut
ouvrir deux sessions, mais si l'utilisateur modifie la même chose dans
deux fenêtres, est-ce à moi de le gérer ? Dans ces conditions, en tout
cas, il n'y aurait pas de problème d'accès concurrentiel, et donc le
stockage dans des fichiers est adapté.

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.


Les UNIQUE PRIMARY, etc c'est vrai que ça ne sera pas géré en XML.
L'avantage du XML, c'est de pouvoir faire une version "standalone" de mon
logiciel avec les mêmes données et sans installer de serveur de base de
données sur le poste de chaque utilisateur.

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


actuellement ça met 0.7s pour charger une page. Mais bon, les 480 requêtes
y sont pour quelque chose :) je vais déjà essayer de modifier cela.

Damien


Avatar
John Gallet
fonction de comprendre que puisque print retourne une valeur entière
alors que echo non cette dernière s'executera fondamentalement plus
rapidement.


Mais tout ça on le sait déjà depuis Mathusalem, Rasmus l'a déjà dit.

Celà dit echo et print ne s'utiliseront donc pas de la même manière.
Parce que tu en connais beaucoup des dévelopeurs qui vérifient le retour

de la fonction print pour savoir si elle a échoué ? Déjà qu'on arrive
pas à leur faire comprendre qu'il faut le faire sur les fonctions de
connexion de SGBDR, ça m'étonnerait que ça vienne à l'idée de quiconque.
Et là ce serait vraiemnt du temps perdu. Si ton print renvoie FALSE, tu
vas faire quoi ? Tu renvoies une exception pour que la couche du dessus
se débrouille ?

En tous cas une chose est sûre : on a perdu plus de temps à expliquer
pourquoi on se fout totalement d'utiliser l'un ou l'autre qu'il n'y aura
de cycles CPU gagnés pendant les dix ans à venir sur tous les serveurs
de France et de Navarre par l'utilisation soit disant préconisée de echo
au lieu de print.

a++
JG

Avatar
nano
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


KDO,

Non-spécialiste, j'ai trouvé ton article intéressant.

La polémique portant sur l'utilisation de print de préférence à echo, ou
vice versa, se résume personnellement à cette règle :

j'utilise print dans tous les cas, sauf dans une structure de type

$variable = ( condition ) ? print "quelque chose" : print "autre chose";

simplement parce que echo ne fonctionne pas dans ce cas.

Juste pour mettre mon grain de sel,

JJS.

Avatar
Laurent Seguin
John Gallet , le 13 mai 2004 13:16:28, écrivait
ceci:

Si ton print renvoie FALSE, tu vas faire quoi ?


On essaye avec echo ? (patapé)

Avatar
Laurent Seguin
KDO , le 12 mai 2004 00:12:48, écrivait ceci:

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


Vite vite, je lance VI sur tous mes script et je remplace tous mes print,
je devait gagner bien 20ms !!! T'as rien de plus intéréssant à nous faire
partager comme analyse ?
Perso je serais intéréssé de savoir quelle est la meilleure manière de se
connecter à un MySQL, il faut faire une classe ou une simple fonction ?
hein ? dis ? c'est quoi qu'est mieux ?

Avatar
Olivier Miakinen

j'utilise print dans tous les cas,


"echo", je suppose, vu la suite de la phrase.

sauf dans une structure de type
$variable = ( condition ) ? print "quelque chose" : print "autre chose";


Autant j'aime bien la construction "?:", autant je ne vois pas ce
qu'elle apporte ici, vu que le code de retour est toujours le même, et
que donc affecter $variable n'a que peu d'intérêt.

Avatar
nano
Olivier Miakinen <om+ wrote:


j'utilise print dans tous les cas,


"echo", je suppose, vu la suite de la phrase.

sauf dans une structure de type
$variable = ( condition ) ? print "quelque chose" : print "autre chose";


Autant j'aime bien la construction "?:", autant je ne vois pas ce
qu'elle apporte ici, vu que le code de retour est toujours le même, et
que donc affecter $variable n'a que peu d'intérêt.


Olivier,

oups... deux bêtises dans le même message, ça fait beaucoup :-(

C'est bien entendu "echo" pour la première et, en ce qui concerne la
deuxième, c'est ( condition ) ? print "qqchoz" : print "aut'choz";

Tout confus,

JJS.

P.S.: Une autre sorte de record de lenteur dans la propagation des
nouvelles, la réponse faite à Seb date de jeudi 13, soit 4 jours !


Avatar
Armel FAUVEAU
Bonsoir,

Si ton print renvoie FALSE, tu vas faire quoi ?


On essaye avec echo ? (patapé)


MDR :)

Armel.


Avatar
Johannes Schlueter
John Gallet wrote:

Si ton print renvoie FALSE, tuvas faire quoi ?


Ce n'est pas possible. "print" renvoie seulement TRUE donc on peux faire

--
$ php -r "false or print 'Bonjour';"
Bonjour
--

Donc, dans un script PHP réaliste on peux faire ça:

<?php
mysql_connect(...) or print "Problème";
?>

Mais avec "echo" ce n'est pas pssible:

--
$ php -r "false or echo 'Bonjour';"

Parse error: parse error in Command line code on line 1
--

Une explication des différences de echo et print est disponible à FAQTs (en
anglais)
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

johannes

Avatar
Olivier Miakinen

[...] en ce qui concerne la
deuxième, c'est ( condition ) ? print "qqchoz" : print "aut'choz";


... et je renouvelle ma remarque.

Autant je comprends bien l'intérêt de la construction « $variable (condition) ? $valeur1 : $valeur2; », autant je ne vois pas pourquoi
dans ton cas tu ne fais pas « if (condition) echo "qqch"; else echo
"aut'ch"; »

En revanche, l'exemple de Johannes me semble plus facilement recevable.

1 2 3 4