"Bonne pratique" ou "Optimisation" : afficher une grosse variable texte ou plusieurs petites ?
19 réponses
Damien
Bonjour,
Grâce à plusieurs conseils sur ce group et d'autres, je suis en train de
'nettoyer' mon code. Je m'intéresse aussi à faire en sorte que mes pages
"résultats de requête" soient les plus propres et rapides possibles.
Quelle est technique la plus propre (vitesse, mémoire...) :
Méthode 1 :
Récupérer un enregistrement,
Le travailler
L'afficher (echo)
Récupérer...
Méthode 2 :
Récupérer un enregistrement
Le travailler
L'ajouter au bout d'une variable
Récupérer...
[...]
Enfin : afficher la grosse variable.
Des idées ? Pistes ?
Merci d'avance !
--
Damien
">sigh< They must think we came down in the last service pack..."
BOFH
Méthode 2 : Récupérer un enregistrement Le travailler L'ajouter au bout d'une variable Récupérer... [...] Enfin : afficher la grosse variable.
oui et mieux qu'une grosse variable, utiliser ob_flush et cie.
Mnt c'est une réponse à la louche. Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec chaque solution et publier ;)
Nadine St-Amand
A mon avis,
en toute logique
la methode 1 (echo) est plus lente mais plus econome en memoire la methode 2 (accumulation) est plus rapide puisqu'elle economise le nombre d'echo, mais coute un petit peu plus cher a la memoire du serveur.
ceci dit, cela depend de ce qui se passe avec cette enorme chaine, si elle est copiee a droite et a gauche avant d'aboutir dans l'echo, cela peut rallonger le temps d'execution au lieu de l'optimiser.
Mais seul ceux qui ont ecrit l'interpreteur php pourraient repondre avec certitude a la question.
Nadine
A mon avis,
en toute logique
la methode 1 (echo) est plus lente mais plus econome en memoire
la methode 2 (accumulation) est plus rapide puisqu'elle economise le
nombre d'echo, mais coute un petit peu plus cher a la memoire du serveur.
ceci dit, cela depend de ce qui se passe avec cette enorme chaine,
si elle est copiee a droite et a gauche avant d'aboutir dans l'echo,
cela peut rallonger le temps d'execution au lieu de l'optimiser.
Mais seul ceux qui ont ecrit l'interpreteur php pourraient repondre avec
certitude a la question.
la methode 1 (echo) est plus lente mais plus econome en memoire la methode 2 (accumulation) est plus rapide puisqu'elle economise le nombre d'echo, mais coute un petit peu plus cher a la memoire du serveur.
ceci dit, cela depend de ce qui se passe avec cette enorme chaine, si elle est copiee a droite et a gauche avant d'aboutir dans l'echo, cela peut rallonger le temps d'execution au lieu de l'optimiser.
Mais seul ceux qui ont ecrit l'interpreteur php pourraient repondre avec certitude a la question.
Nadine
loufoque
Damien a dit le 27/05/2005 18:09:
Bonjour, Grâce à plusieurs conseils sur ce group et d'autres, je suis en train de 'nettoyer' mon code. Je m'intéresse aussi à faire en sorte que mes pages "résultats de requête" soient les plus propres et rapides possibles.
PHP bufférise déjà automatiquement comme il faut.
Damien a dit le 27/05/2005 18:09:
Bonjour,
Grâce à plusieurs conseils sur ce group et d'autres, je suis en train de
'nettoyer' mon code. Je m'intéresse aussi à faire en sorte que mes pages
"résultats de requête" soient les plus propres et rapides possibles.
Bonjour, Grâce à plusieurs conseils sur ce group et d'autres, je suis en train de 'nettoyer' mon code. Je m'intéresse aussi à faire en sorte que mes pages "résultats de requête" soient les plus propres et rapides possibles.
PHP bufférise déjà automatiquement comme il faut.
Marc
Des idées ? Pistes ?
la tendance actuelle surtout dans les classes et de generer une chaine de caractere en sortie de methode plutot que d'afficher ; c'est a la classe ou application de savoir ce quelle doit faire avec la chaine : affichage, transcodage ou autre.
donc ce principe appliqué à la vitesse de traitement n'a pas beaucoup de sens. Je dirai meme que stoker en memoire du texte pour l'afficher le plus tard possible ne peut que nuire aux performance.
A toi de faire le choix entre reutilisabilité, si tu en trouve une dans ton code et vitesse.
Des idées ? Pistes ?
la tendance actuelle surtout dans les classes et de generer une
chaine de caractere en sortie de methode plutot que d'afficher ;
c'est a la classe ou application de savoir ce quelle doit faire
avec la chaine : affichage, transcodage ou autre.
donc ce principe appliqué à la vitesse de traitement n'a pas
beaucoup de sens. Je dirai meme que stoker en memoire du
texte pour l'afficher le plus tard possible ne peut que nuire
aux performance.
A toi de faire le choix entre reutilisabilité, si tu en
trouve une dans ton code et vitesse.
la tendance actuelle surtout dans les classes et de generer une chaine de caractere en sortie de methode plutot que d'afficher ; c'est a la classe ou application de savoir ce quelle doit faire avec la chaine : affichage, transcodage ou autre.
donc ce principe appliqué à la vitesse de traitement n'a pas beaucoup de sens. Je dirai meme que stoker en memoire du texte pour l'afficher le plus tard possible ne peut que nuire aux performance.
A toi de faire le choix entre reutilisabilité, si tu en trouve une dans ton code et vitesse.
Damien
(snip)>
oui et mieux qu'une grosse variable, utiliser ob_flush et cie.
Merci pour cette suggestion, je vais jeter un oeil au man.
Mnt c'est une réponse à la louche. Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec chaque solution et publier ;)
:) je vais faire ça demain ;) Cheers, -- Damien
(snip)>
oui et mieux qu'une grosse variable, utiliser ob_flush et cie.
Merci pour cette suggestion, je vais jeter un oeil au man.
Mnt c'est une réponse à la louche.
Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec
chaque solution et publier ;)
oui et mieux qu'une grosse variable, utiliser ob_flush et cie.
Merci pour cette suggestion, je vais jeter un oeil au man.
Mnt c'est une réponse à la louche. Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec chaque solution et publier ;)
:) je vais faire ça demain ;) Cheers, -- Damien
Damien
(snip)
Mnt c'est une réponse à la louche. Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec chaque solution et publier ;)
Bonjour, Voici les résultats de mes "benches" : Méthode 1 : 1 echo à chaque ligne, pas d'utilisation de ob_start() Méthode 2 : 1 echo mais utilisation de ob_start() Méthode 3 : Toutes les infos concaténées dans 1 variable, 1 seul echo.
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête" sont des phases en principe non affectées par le flush.
Rien de bien significatif, ça se joue au millième près. Pas trop de changement en augmentant le tampon (la taille du tableau affiché).
DONC je reste sur la méthode de l'écho, mais "pour faire propre" je vais essayer de généraliser l'utilisation de ob_start et cie.
Voilà ! @+ -- Damien
(snip)
Mnt c'est une réponse à la louche.
Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec
chaque solution et publier ;)
Bonjour,
Voici les résultats de mes "benches" :
Méthode 1 : 1 echo à chaque ligne, pas d'utilisation de ob_start()
Méthode 2 : 1 echo mais utilisation de ob_start()
Méthode 3 : Toutes les infos concaténées dans 1 variable, 1 seul echo.
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête"
sont des phases en principe non affectées par le flush.
Mnt c'est une réponse à la louche. Si tu as du temps, tu fais ce qu'on devrait tous faire : des bench avec chaque solution et publier ;)
Bonjour, Voici les résultats de mes "benches" : Méthode 1 : 1 echo à chaque ligne, pas d'utilisation de ob_start() Méthode 2 : 1 echo mais utilisation de ob_start() Méthode 3 : Toutes les infos concaténées dans 1 variable, 1 seul echo.
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête" sont des phases en principe non affectées par le flush.
Rien de bien significatif, ça se joue au millième près. Pas trop de changement en augmentant le tampon (la taille du tableau affiché).
DONC je reste sur la méthode de l'écho, mais "pour faire propre" je vais essayer de généraliser l'utilisation de ob_start et cie.
Voilà ! @+ -- Damien
Guillaume Bouchard
Damien wrote:
Voici les résultats de mes "benches" :
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête" sont des phases en principe non affectées par le flush.
Total 0.0634 0.0629 0.0642
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers (millions ?) de valeurs pour distinguer un reel ecart.
Pour peu qu'a ce moment precit tu es un acces disque en trop et paaf, tu te prend 50 % du temps en plus.
DONC je reste sur la méthode de l'écho, mais "pour faire propre" je vais essayer de généraliser l'utilisation de ob_start et cie.
Reste sur la méthode qui te semble la plus propre, la plus simple à implanter, la plus lisible et maitenable et tu auras la bonne methode.
<mode pere castor> Un jour un amis de ma connaissance coda un forum pour son site web. AU debut tout allait bien, mais aprés quelques semaines, le forum mettait plus de 10 secondes à trouver un message.
L'amis de ma conaissance m'expliqua que pour optimiser il allait changer toutes les doubles quotes en simple quotes et tous les print en echo car c'est plus rapide. L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra l'histoire c'est que je lui ai proposer de poser quelques index sur ces tables et que soudain le forum est rapassé en dessous de la barre de 0.1 secondes </pere castor>
Moralité : C'est faire beaucoup de mal à une pauvre mouche que de parler d'optimisation sur des problèmes comme ceux-ci.
-- Guillaume.
Damien wrote:
Voici les résultats de mes "benches" :
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête"
sont des phases en principe non affectées par le flush.
Total 0.0634 0.0629 0.0642
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans
problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers
(millions ?) de valeurs pour distinguer un reel ecart.
Pour peu qu'a ce moment precit tu es un acces disque en trop et paaf, tu
te prend 50 % du temps en plus.
DONC je reste sur la méthode de l'écho, mais "pour faire propre" je vais
essayer de généraliser l'utilisation de ob_start et cie.
Reste sur la méthode qui te semble la plus propre, la plus simple à
implanter, la plus lisible et maitenable et tu auras la bonne methode.
<mode pere castor>
Un jour un amis de ma connaissance coda un forum pour son site web.
AU debut tout allait bien, mais aprés quelques semaines, le forum
mettait plus de 10 secondes à trouver un message.
L'amis de ma conaissance m'expliqua que pour optimiser il allait changer
toutes les doubles quotes en simple quotes et tous les print en echo car
c'est plus rapide.
L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra
l'histoire c'est que je lui ai proposer de poser quelques index sur ces
tables et que soudain le forum est rapassé en dessous de la barre de 0.1
secondes
</pere castor>
Moralité : C'est faire beaucoup de mal à une pauvre mouche que de parler
d'optimisation sur des problèmes comme ceux-ci.
Le tampon a une taille de 8581 caractères (?). "Comptage" et "requête" sont des phases en principe non affectées par le flush.
Total 0.0634 0.0629 0.0642
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers (millions ?) de valeurs pour distinguer un reel ecart.
Pour peu qu'a ce moment precit tu es un acces disque en trop et paaf, tu te prend 50 % du temps en plus.
DONC je reste sur la méthode de l'écho, mais "pour faire propre" je vais essayer de généraliser l'utilisation de ob_start et cie.
Reste sur la méthode qui te semble la plus propre, la plus simple à implanter, la plus lisible et maitenable et tu auras la bonne methode.
<mode pere castor> Un jour un amis de ma connaissance coda un forum pour son site web. AU debut tout allait bien, mais aprés quelques semaines, le forum mettait plus de 10 secondes à trouver un message.
L'amis de ma conaissance m'expliqua que pour optimiser il allait changer toutes les doubles quotes en simple quotes et tous les print en echo car c'est plus rapide. L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra l'histoire c'est que je lui ai proposer de poser quelques index sur ces tables et que soudain le forum est rapassé en dessous de la barre de 0.1 secondes </pere castor>
Moralité : C'est faire beaucoup de mal à une pauvre mouche que de parler d'optimisation sur des problèmes comme ceux-ci.
-- Guillaume.
Damien
(snip)>
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers (millions ?) de valeurs pour distinguer un reel ecart.
Je suis pas non plus développeur :) A moins qu'ont trouve des permis "péhachepé" dans les oeufs kinder :D
Là j'ai lancé quelques fois le "truc" pour chaque méthode, juste pour comparer. Rien de terrible. D'où, aussi, ma conclusion : écart pas significatif. Donc pas besoin non plus de sortir le Leclerc. Ou le panzer. Ou le zébulateur à ions.
(snip)
L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra l'histoire c'est que je lui ai proposer de poser quelques index sur ces tables et que soudain le forum est rapassé en dessous de la barre de 0.1 secondes </pere castor> (snip)
Ca c'est une autre question, que je suis d'ailleurs en train de me poser :) Comment faire des beaux zindex... Pas trouvé de tutoriel, à propos. Si tu as des conseils ?
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis aux simple quotes récement à la suite de divers débats sur ce groupe :)
Bonne nuit, -- Damien
"Je préfère glisser ma peau sous les draps pour le plaisirs des sens, plutôt que la risquer sous les drapeaux, pour de l'essence"
Raymond Devos
(snip)>
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans
problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers
(millions ?) de valeurs pour distinguer un reel ecart.
Je suis pas non plus développeur :) A moins qu'ont trouve des permis
"péhachepé" dans les oeufs kinder :D
Là j'ai lancé quelques fois le "truc" pour chaque méthode, juste pour
comparer. Rien de terrible. D'où, aussi, ma conclusion : écart pas
significatif. Donc pas besoin non plus de sortir le Leclerc. Ou le
panzer. Ou le zébulateur à ions.
(snip)
L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra
l'histoire c'est que je lui ai proposer de poser quelques index sur ces
tables et que soudain le forum est rapassé en dessous de la barre de 0.1
secondes
</pere castor>
(snip)
Ca c'est une autre question, que je suis d'ailleurs en train de me poser
:) Comment faire des beaux zindex... Pas trouvé de tutoriel, à propos.
Si tu as des conseils ?
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis
aux simple quotes récement à la suite de divers débats sur ce groupe :)
Bonne nuit,
--
Damien
"Je préfère glisser ma peau sous les draps pour le plaisirs des sens,
plutôt que la risquer sous les drapeaux, pour de l'essence"
C'est pas du bench ça !!! Le script que j'ai sous la main fluctue sans problème entre 0.1 et 0.03. Un bon bench se fait sur des miliers (millions ?) de valeurs pour distinguer un reel ecart.
Je suis pas non plus développeur :) A moins qu'ont trouve des permis "péhachepé" dans les oeufs kinder :D
Là j'ai lancé quelques fois le "truc" pour chaque méthode, juste pour comparer. Rien de terrible. D'où, aussi, ma conclusion : écart pas significatif. Donc pas besoin non plus de sortir le Leclerc. Ou le panzer. Ou le zébulateur à ions.
(snip)
L'histoire ne dit pas si il l'a reelement fait ou bien, ce que retiendra l'histoire c'est que je lui ai proposer de poser quelques index sur ces tables et que soudain le forum est rapassé en dessous de la barre de 0.1 secondes </pere castor> (snip)
Ca c'est une autre question, que je suis d'ailleurs en train de me poser :) Comment faire des beaux zindex... Pas trouvé de tutoriel, à propos. Si tu as des conseils ?
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis aux simple quotes récement à la suite de divers débats sur ce groupe :)
Bonne nuit, -- Damien
"Je préfère glisser ma peau sous les draps pour le plaisirs des sens, plutôt que la risquer sous les drapeaux, pour de l'essence"
Raymond Devos
Olivier Miakinen
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis aux simple quotes récement à la suite de divers débats sur ce groupe :)
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML !
C'est-à-dire qu'au lieu de faire : $machin = '<a href="' . $bidule . '">';
ou de faire : $machin = "<a href="$bidule">";
je fais : $machin = "<a href='$bidule'>";
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais qu'est-ce que je gagne en lisibilité du code !
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis
aux simple quotes récement à la suite de divers débats sur ce groupe :)
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML !
C'est-à-dire qu'au lieu de faire :
$machin = '<a href="' . $bidule . '">';
ou de faire :
$machin = "<a href="$bidule">";
je fais :
$machin = "<a href='$bidule'>";
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais
qu'est-ce que je gagne en lisibilité du code !
Juste pour rebondir sur ta petite histoire, je me suis effectivement mis aux simple quotes récement à la suite de divers débats sur ce groupe :)
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML !
C'est-à-dire qu'au lieu de faire : $machin = '<a href="' . $bidule . '">';
ou de faire : $machin = "<a href="$bidule">";
je fais : $machin = "<a href='$bidule'>";
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais qu'est-ce que je gagne en lisibilité du code !
John Gallet
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML ! C'est mal (C).
Vous ne verrez jamais participer à un pseudo débat sur la "qualité" du code (x)html mais *d'expérience empirique* sur la compatibilité entre navigateurs (non y'a pas que IE et godzilla dans la vie) il y deux choses, et deux choses seulement, auxquelles je fais très attention quand je génère du html :
1) toujours utiliser des " pour tous les attributs. Sinon ça *peut* foutre le bordel. 2) ne jamais mettre d'espaces dans les noms de variables (ni au milieu, ni en début ou fin), sinon certains navigateurs (opéra en particulier) remplacent les espaces par des _ Donc écriture correcte : <INPUT TYPE="TEXT" NAME="coucou" VALUE="coincoin"> Ecriture incorrecte double : ... NAME=' coucou' ....
Le reste on s'en tape, mais ça c'est important pour la compatibilité.
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais qu'est-ce que je gagne en lisibilité du code !
Tout à fait d'accord sur ce critère déterminant la lisibilité du code: le reste c'est de l'enculage de mouches.
Donc perso j'utilise des " en PHP pour générer du SQL (vu qu'en SQL, c'est ' qu'on utilise) et j'utilise des ' en PHP pour le HTML (vu que c'est " qu'on doit utiliser). Quand à savoir ce qui prend le plus de temps, on en a "discuté" des centaines de fois, c'est non mesurable par rapport au temps perdu dans des algorithmes écrits avec les pied et en particulier les requêtes SQL qui ne servent à rien parce que les gens ne savent pas ce qu'est une clef primaire/unique.
a++; JG
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML !
C'est mal (C).
Vous ne verrez jamais participer à un pseudo débat sur la "qualité" du
code (x)html mais *d'expérience empirique* sur la compatibilité entre
navigateurs (non y'a pas que IE et godzilla dans la vie) il y deux
choses, et deux choses seulement, auxquelles je fais très attention
quand je génère du html :
1) toujours utiliser des " pour tous les attributs. Sinon ça *peut*
foutre le bordel.
2) ne jamais mettre d'espaces dans les noms de variables (ni au milieu,
ni en début ou fin), sinon certains navigateurs (opéra en particulier)
remplacent les espaces par des _
Donc écriture correcte : <INPUT TYPE="TEXT" NAME="coucou"
VALUE="coincoin">
Ecriture incorrecte double : ... NAME=' coucou' ....
Le reste on s'en tape, mais ça c'est important pour la compatibilité.
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais
qu'est-ce que je gagne en lisibilité du code !
Tout à fait d'accord sur ce critère déterminant la lisibilité du code:
le reste c'est de l'enculage de mouches.
Donc perso j'utilise des " en PHP pour générer du SQL (vu qu'en SQL,
c'est ' qu'on utilise) et j'utilise des ' en PHP pour le HTML (vu que
c'est " qu'on doit utiliser). Quand à savoir ce qui prend le plus de
temps, on en a "discuté" des centaines de fois, c'est non mesurable par
rapport au temps perdu dans des algorithmes écrits avec les pied et en
particulier les requêtes SQL qui ne servent à rien parce que les gens ne
savent pas ce qu'est une clef primaire/unique.
Quant à moi, je me suis mis aux « simple quotes »... pour le HTML ! C'est mal (C).
Vous ne verrez jamais participer à un pseudo débat sur la "qualité" du code (x)html mais *d'expérience empirique* sur la compatibilité entre navigateurs (non y'a pas que IE et godzilla dans la vie) il y deux choses, et deux choses seulement, auxquelles je fais très attention quand je génère du html :
1) toujours utiliser des " pour tous les attributs. Sinon ça *peut* foutre le bordel. 2) ne jamais mettre d'espaces dans les noms de variables (ni au milieu, ni en début ou fin), sinon certains navigateurs (opéra en particulier) remplacent les espaces par des _ Donc écriture correcte : <INPUT TYPE="TEXT" NAME="coucou" VALUE="coincoin"> Ecriture incorrecte double : ... NAME=' coucou' ....
Le reste on s'en tape, mais ça c'est important pour la compatibilité.
Je perds peut-être un demi-pouillème de microseconde à l'exécution, mais qu'est-ce que je gagne en lisibilité du code !
Tout à fait d'accord sur ce critère déterminant la lisibilité du code: le reste c'est de l'enculage de mouches.
Donc perso j'utilise des " en PHP pour générer du SQL (vu qu'en SQL, c'est ' qu'on utilise) et j'utilise des ' en PHP pour le HTML (vu que c'est " qu'on doit utiliser). Quand à savoir ce qui prend le plus de temps, on en a "discuté" des centaines de fois, c'est non mesurable par rapport au temps perdu dans des algorithmes écrits avec les pied et en particulier les requêtes SQL qui ne servent à rien parce que les gens ne savent pas ce qu'est une clef primaire/unique.
