je me demande si le moteur de Php optimise le code quand on emploi des constantes avec define().
par exemple est-ce que le code encapsulé dans un if() sur une constante est compilé ?
par exemple :
Si vous connaissez des optimisations, je susi preneur !
merci cyrille
Nudrema
[ psykokwak ] wrote:
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Oui, mais si le monsieur il veut définir une constante DEBUG pour activer le mode de débuggage sur tout son site (compter sacwantes appels sur chaque page), pour éviter qu'un petit malin ne se serve de register-globals pour polluer un $debug, s'il n'utilise pas la constante, il risque de devoir chipoter, non, sans la constante ?
-- Nudrema (S.F.)
http://tw.o0o.ch
[ psykokwak ] wrote:
maintenant si tu defini une constante a FALSE pour une condition!
autant ecrire if(FALSE){ ... } directement ;)
Oui, mais si le monsieur il veut définir une constante DEBUG pour
activer le mode de débuggage sur tout son site (compter sacwantes
appels sur chaque page), pour éviter qu'un petit malin ne se
serve de register-globals pour polluer un $debug, s'il n'utilise
pas la constante, il risque de devoir chipoter, non, sans la
constante ?
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Oui, mais si le monsieur il veut définir une constante DEBUG pour activer le mode de débuggage sur tout son site (compter sacwantes appels sur chaque page), pour éviter qu'un petit malin ne se serve de register-globals pour polluer un $debug, s'il n'utilise pas la constante, il risque de devoir chipoter, non, sans la constante ?
-- Nudrema (S.F.)
http://tw.o0o.ch
jz
[ psykokwak ] wrote:
moarf! le php est un language IN-TER-PRE-TE et non pas compilé! donc quoique tu fasse, ca ramera tout autant ;)
C'est pas la peine de crier. Qu'est-ce qui te permets d'être aussi péremtoire pour affirmer cela. Il existe déjà des compilateurs php. Rien n'empêche de penser que le serveur précompile les scripts avant de les exécuter la première fois, puis ensuite utilise la version compilée tant que les sources ne sont pas modifiés. C'est une évolution tout à fait abordable pour un programme capable d'interpréter le langage. Le seul vrai soucis concerne la sécurité, car il ne faut pas que le module php ait des droits éxagérés sur la machine serveur. C'est plus facile à contrôler ligne par ligne lors de chaque interprétation que dans un module déjà compilé qui peut avoir été trafiqué après.
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Ta réponse est plutôt ridicule. Tu n'as pas compris l'un des rôles fondamentaux en programmation des constantes : pouvoir contrôler le comportement complet d'une application en ajustant seulement une ligne de code. C'est particulièrement utile lors de la phase de développement d'un projet un peu lourd.
(normalement if(0) marche aussi)
Là tu aurais dû mettre un smiley, tu es très drôle.
Jacques
[ psykokwak ] wrote:
moarf!
le php est un language IN-TER-PRE-TE et non pas compilé!
donc quoique tu fasse, ca ramera tout autant ;)
C'est pas la peine de crier. Qu'est-ce qui te permets d'être aussi
péremtoire pour affirmer cela. Il existe déjà des compilateurs php. Rien
n'empêche de penser que le serveur précompile les scripts avant de les
exécuter la première fois, puis ensuite utilise la version compilée tant
que les sources ne sont pas modifiés. C'est une évolution tout à fait
abordable pour un programme capable d'interpréter le langage. Le seul
vrai soucis concerne la sécurité, car il ne faut pas que le module php
ait des droits éxagérés sur la machine serveur. C'est plus facile à
contrôler ligne par ligne lors de chaque interprétation que dans un
module déjà compilé qui peut avoir été trafiqué après.
maintenant si tu defini une constante a FALSE pour une condition!
autant ecrire if(FALSE){ ... } directement ;)
Ta réponse est plutôt ridicule. Tu n'as pas compris l'un des rôles
fondamentaux en programmation des constantes : pouvoir contrôler le
comportement complet d'une application en ajustant seulement une ligne
de code. C'est particulièrement utile lors de la phase de développement
d'un projet un peu lourd.
(normalement if(0) marche aussi)
Là tu aurais dû mettre un smiley, tu es très drôle.
moarf! le php est un language IN-TER-PRE-TE et non pas compilé! donc quoique tu fasse, ca ramera tout autant ;)
C'est pas la peine de crier. Qu'est-ce qui te permets d'être aussi péremtoire pour affirmer cela. Il existe déjà des compilateurs php. Rien n'empêche de penser que le serveur précompile les scripts avant de les exécuter la première fois, puis ensuite utilise la version compilée tant que les sources ne sont pas modifiés. C'est une évolution tout à fait abordable pour un programme capable d'interpréter le langage. Le seul vrai soucis concerne la sécurité, car il ne faut pas que le module php ait des droits éxagérés sur la machine serveur. C'est plus facile à contrôler ligne par ligne lors de chaque interprétation que dans un module déjà compilé qui peut avoir été trafiqué après.
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Ta réponse est plutôt ridicule. Tu n'as pas compris l'un des rôles fondamentaux en programmation des constantes : pouvoir contrôler le comportement complet d'une application en ajustant seulement une ligne de code. C'est particulièrement utile lors de la phase de développement d'un projet un peu lourd.
(normalement if(0) marche aussi)
Là tu aurais dû mettre un smiley, tu es très drôle.
Jacques
Guillaume Bouchard
[ psykokwak ] wrote:
moarf! le php est un language IN-TER-PRE-TE et non pas compilé! donc quoique tu fasse, ca ramera tout autant ;)
<troll> Pas autant que l'asp </trool>
Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou autres.
-- Guillaume.
[ psykokwak ] wrote:
moarf!
le php est un language IN-TER-PRE-TE et non pas compilé!
donc quoique tu fasse, ca ramera tout autant ;)
<troll>
Pas autant que l'asp
</trool>
Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait
vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou
autres.
moarf! le php est un language IN-TER-PRE-TE et non pas compilé! donc quoique tu fasse, ca ramera tout autant ;)
<troll> Pas autant que l'asp </trool>
Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou autres.
-- Guillaume.
John Gallet
Bonjour,
le php est un language IN-TER-PRE-TE et non pas compilé!
Il est exact que le terme employé, compilé est impropre, on devrait dire "parsé" (en français dans le texte, sopo la loi AllGood). Néanmoins ne pas oublier la notion d'encoders (Zend Encoder, ionCube, etc...) qui permettent une véritable compilation tout à fait équivalente à la production d'un .class à partir d'un .java. D'ailleur ça me fait penser que j'avais un retour d'expérience à demander, j'y cours dès que j'ai finit ce post.
donc quoique tu fasse, ca ramera tout autant ;) Il n'y a pas péril en la demeure non plus hein...
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu ne comprends pas la différence entre une variable et une constante, et encore moins la notion de niveau de traces.
a++; JG
Bonjour,
le php est un language IN-TER-PRE-TE et non pas compilé!
Il est exact que le terme employé, compilé est impropre, on devrait dire
"parsé" (en français dans le texte, sopo la loi AllGood). Néanmoins ne pas
oublier la notion d'encoders (Zend Encoder, ionCube, etc...) qui permettent
une véritable compilation tout à fait équivalente à la production d'un
.class à partir d'un .java. D'ailleur ça me fait penser que j'avais un
retour d'expérience à demander, j'y cours dès que j'ai finit ce post.
donc quoique tu fasse, ca ramera tout autant ;)
Il n'y a pas péril en la demeure non plus hein...
maintenant si tu defini une constante a FALSE pour une condition!
autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au
dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu
ne comprends pas la différence entre une variable et une constante, et
encore moins la notion de niveau de traces.
le php est un language IN-TER-PRE-TE et non pas compilé!
Il est exact que le terme employé, compilé est impropre, on devrait dire "parsé" (en français dans le texte, sopo la loi AllGood). Néanmoins ne pas oublier la notion d'encoders (Zend Encoder, ionCube, etc...) qui permettent une véritable compilation tout à fait équivalente à la production d'un .class à partir d'un .java. D'ailleur ça me fait penser que j'avais un retour d'expérience à demander, j'y cours dès que j'ai finit ce post.
donc quoique tu fasse, ca ramera tout autant ;) Il n'y a pas péril en la demeure non plus hein...
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu ne comprends pas la différence entre une variable et une constante, et encore moins la notion de niveau de traces.
a++; JG
John Gallet
Bonjour,
je me demande si le moteur de Php optimise le code quand on emploi des constantes avec define().
par exemple est-ce que le code encapsulé dans un if() sur une constante est compilé ?
De mémoire, seule l'instruction include() peut être parsée contextuellement. Donc si tu fais : if(DEBUG=úlse) include('toto.php');
alors toto.php ne sera parsé (et exécuté) que dans le cas 'kivabien'.
De manière générale, les instructions de debug sont des traces supplémentaires que l'on souhaite voir apparaître dans le cas où le mode est activé. Personnellement, j'appelle donc une fonction (originalement appelée debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de la fonction debug commence par : if(NIVEAU_DEBUG=='none') return; Et sinon, selon mon niveau de debug, je fais ce qu'il faut faire (traces en commentaires html, en clair à l'écran, etc...). Le temps de parsing supplémentaire est donc égal au nombre d'appels à la fonction. Le temps perdu au runtime si on est en mode non débug est égal à l'empilement d'une fonction et un test. Quand je n'aurais plus que cette partie là à optimiser, on en reparlera, en attendant, c'est en prod depuis mathusalem et personne n'a à s'en plaindre.
a++ JG
Bonjour,
je me demande si le moteur de Php optimise le code quand on emploi des
constantes avec define().
par exemple est-ce que le code encapsulé dans un if() sur une constante est
compilé ?
De mémoire, seule l'instruction include() peut être parsée contextuellement.
Donc si tu fais :
if(DEBUG=úlse)
include('toto.php');
alors toto.php ne sera parsé (et exécuté) que dans le cas 'kivabien'.
De manière générale, les instructions de debug sont des traces
supplémentaires que l'on souhaite voir apparaître dans le cas où le mode est
activé. Personnellement, j'appelle donc une fonction (originalement appelée
debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de
la fonction debug commence par :
if(NIVEAU_DEBUG=='none') return;
Et sinon, selon mon niveau de debug, je fais ce qu'il faut faire (traces en
commentaires html, en clair à l'écran, etc...).
Le temps de parsing supplémentaire est donc égal au nombre d'appels à la
fonction. Le temps perdu au runtime si on est en mode non débug est égal à
l'empilement d'une fonction et un test. Quand je n'aurais plus que cette
partie là à optimiser, on en reparlera, en attendant, c'est en prod depuis
mathusalem et personne n'a à s'en plaindre.
je me demande si le moteur de Php optimise le code quand on emploi des constantes avec define().
par exemple est-ce que le code encapsulé dans un if() sur une constante est compilé ?
De mémoire, seule l'instruction include() peut être parsée contextuellement. Donc si tu fais : if(DEBUG=úlse) include('toto.php');
alors toto.php ne sera parsé (et exécuté) que dans le cas 'kivabien'.
De manière générale, les instructions de debug sont des traces supplémentaires que l'on souhaite voir apparaître dans le cas où le mode est activé. Personnellement, j'appelle donc une fonction (originalement appelée debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de la fonction debug commence par : if(NIVEAU_DEBUG=='none') return; Et sinon, selon mon niveau de debug, je fais ce qu'il faut faire (traces en commentaires html, en clair à l'écran, etc...). Le temps de parsing supplémentaire est donc égal au nombre d'appels à la fonction. Le temps perdu au runtime si on est en mode non débug est égal à l'empilement d'une fonction et un test. Quand je n'aurais plus que cette partie là à optimiser, on en reparlera, en attendant, c'est en prod depuis mathusalem et personne n'a à s'en plaindre.
a++ JG
cyrille
De mémoire, seule l'instruction include() peut être parsée contextuellement. Donc si tu fais : if(DEBUG=úlse) include('toto.php');
ha ba oui. mais c'est dommage.
en Perl, le compilo (ou interpréteur, parser mais on s'en fou, à ce niveau on parle de la meme chose), reprend sont travail après l'accolade fermante dans le cas d'un test (if) sur une constante. if( DEBUG ){ ... plein de code } voir http://www.perlmonks.org/index.pl?node_id3154 pour plus d'info
activé. Personnellement, j'appelle donc une fonction (originalement appelée debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de la fonction debug commence par : if(NIVEAU_DEBUG=='none') return;
Je fais pareil. mais dans le cas de boucle pour inspecter des structures de données, les boucles sont toujours compilées. if( DEBUG ){ foreach( $mastruct){ dbgprint(); } }
Merci pour mes défenseur ;o) Yen a un qui est parti dans les choux avec ces if(0) ;o)
cyrille
PS : allez voir l'article sur les constantes en Perl, c'est interressant. ya meme des benchmarks. http://www.perlmonks.org/index.pl?node_id3154
De mémoire, seule l'instruction include() peut être parsée contextuellement.
Donc si tu fais :
if(DEBUG=úlse)
include('toto.php');
ha ba oui.
mais c'est dommage.
en Perl, le compilo (ou interpréteur, parser mais on s'en fou, à ce niveau on parle de la meme chose),
reprend sont travail après l'accolade fermante dans le cas d'un test (if) sur une constante.
if( DEBUG ){
... plein de code
}
voir http://www.perlmonks.org/index.pl?node_id3154 pour plus d'info
activé. Personnellement, j'appelle donc une fonction (originalement appelée
debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de
la fonction debug commence par :
if(NIVEAU_DEBUG=='none') return;
Je fais pareil.
mais dans le cas de boucle pour inspecter des structures de données, les boucles sont toujours compilées.
if( DEBUG ){
foreach( $mastruct){
dbgprint();
}
}
Merci pour mes défenseur ;o)
Yen a un qui est parti dans les choux avec ces if(0)
;o)
cyrille
PS : allez voir l'article sur les constantes en Perl, c'est interressant.
ya meme des benchmarks.
http://www.perlmonks.org/index.pl?node_id3154
De mémoire, seule l'instruction include() peut être parsée contextuellement. Donc si tu fais : if(DEBUG=úlse) include('toto.php');
ha ba oui. mais c'est dommage.
en Perl, le compilo (ou interpréteur, parser mais on s'en fou, à ce niveau on parle de la meme chose), reprend sont travail après l'accolade fermante dans le cas d'un test (if) sur une constante. if( DEBUG ){ ... plein de code } voir http://www.perlmonks.org/index.pl?node_id3154 pour plus d'info
activé. Personnellement, j'appelle donc une fonction (originalement appelée debug()...) à tous les endroits où je pourrais en avoir besoin. Le code de la fonction debug commence par : if(NIVEAU_DEBUG=='none') return;
Je fais pareil. mais dans le cas de boucle pour inspecter des structures de données, les boucles sont toujours compilées. if( DEBUG ){ foreach( $mastruct){ dbgprint(); } }
Merci pour mes défenseur ;o) Yen a un qui est parti dans les choux avec ces if(0) ;o)
cyrille
PS : allez voir l'article sur les constantes en Perl, c'est interressant. ya meme des benchmarks. http://www.perlmonks.org/index.pl?node_id3154
MERCIER Pascal
cyrille wrote:
hello,
je me demande si le moteur de Php optimise le code quand on emploi des constantes avec define(). par exemple est-ce que le code encapsulé dans un if() sur une constante est compilé ? par exemple :
Si vous connaissez des optimisations, je susi preneur !
merci cyrille
Installer un cache PHP du genre ionCube PHP Accelerator.
Sans vouloir dire de bétise, votre if( DEBUG ) sera quand même interprété et vérifié quand bien même DEBUG serai une constante.
cyrille wrote:
hello,
je me demande si le moteur de Php optimise le code quand on emploi des
constantes avec define().
par exemple est-ce que le code encapsulé dans un if() sur une constante
est compilé ?
par exemple :
je me demande si le moteur de Php optimise le code quand on emploi des constantes avec define(). par exemple est-ce que le code encapsulé dans un if() sur une constante est compilé ? par exemple :
Si vous connaissez des optimisations, je susi preneur !
merci cyrille
Installer un cache PHP du genre ionCube PHP Accelerator.
Sans vouloir dire de bétise, votre if( DEBUG ) sera quand même interprété et vérifié quand bien même DEBUG serai une constante.
[ psykokwak ]
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu ne comprends pas la différence entre une variable et une constante, et encore moins la notion de niveau de traces.
<mode troll=on> on m'a demandé d'optimiser,j'optimise :D </mode> maintenant autrement que en declarant une constante je ne vois pas vraiment comment faire plus simple et moin lourd! (donc oui, la constante pour ce genre d'utilisation est le meilleur choix a faire) et puis j'ai jamais parlé de variable..
tout ca pour dire je pense que l'optimisation de code a ce niveau me semble assez inutile et ininterressant (comme l'a dit Guillaume Bouchard) "Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou autres. "
maintenant si tu defini une constante a FALSE pour une condition!
autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au
dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu
ne comprends pas la différence entre une variable et une constante, et
encore moins la notion de niveau de traces.
<mode troll=on>
on m'a demandé d'optimiser,j'optimise :D
</mode>
maintenant autrement que en declarant une constante je ne vois pas vraiment
comment faire plus simple et moin lourd!
(donc oui, la constante pour ce genre d'utilisation est le meilleur choix a
faire)
et puis j'ai jamais parlé de variable..
tout ca pour dire je pense que l'optimisation de code a ce niveau me semble
assez inutile et ininterressant (comme l'a dit Guillaume Bouchard)
"Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait
vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou
autres.
"
maintenant si tu defini une constante a FALSE pour une condition! autant ecrire if(FALSE){ ... } directement ;)
Là tu aurais mieux fait de tourner 10 fois tes petits doigts potelés au dessus de ton clavier avant de proférer une telle ânerie qui prouve que tu ne comprends pas la différence entre une variable et une constante, et encore moins la notion de niveau de traces.
<mode troll=on> on m'a demandé d'optimiser,j'optimise :D </mode> maintenant autrement que en declarant une constante je ne vois pas vraiment comment faire plus simple et moin lourd! (donc oui, la constante pour ce genre d'utilisation est le meilleur choix a faire) et puis j'ai jamais parlé de variable..
tout ca pour dire je pense que l'optimisation de code a ce niveau me semble assez inutile et ininterressant (comme l'a dit Guillaume Bouchard) "Bon, a part ca, le truc c'est pas d'optimiser de cette façon qui ne fait vraiment rien gagner, mais dans les requetes SQL, les algos complexes ou autres. "
Jean-Marc Molina
Tu dois venir de C/C++ :)
En C++ on faisait #define DEBUG ou #define RELEASE Puis #ifdef DEBUG... code DEBUG sinon... code RELEASE
En PHP, sans encodeur, il faut voir qu'il n'y a pas de directive de précompilation comme #if, il n'y a qu'un if. Celui-ci est alors parsé, traité, évalué comme tous les autres if du code. L'une des solutions consistent donc à voir 2 includes différents, l'un DEBUG et l'autre RELEASE et de jongler entre les 2. Ça peut donner du code copié-collé à l'arrache, des choses horribles :). Donc le plus simple c'est de s'armer d'un débogueur, d'une bonne conception et d'un encodeur pour optimiser ce qui ne peut l'être sans encodeur. Zend Encoder prend ton code, élimine automatiquement tous ces ifs inutiles vu que DEBUG est à FALSE et tu te retrouves donc avec une application 100% DEBUG ou 100% RELEASE.
Sinon comme te la dit Guillaume il faut regarder tes boucles critiques. Un bon outil, le profiler, je te conseille d'essayer celui de Zend. Il y a aussi phpEd, à essayer je n'ai pas encore eu le temps. J'ai été déçu par Zend alors je vais voir du côté de NuSphere...
JM
Tu dois venir de C/C++ :)
En C++ on faisait #define DEBUG ou #define RELEASE
Puis #ifdef DEBUG... code DEBUG sinon... code RELEASE
En PHP, sans encodeur, il faut voir qu'il n'y a pas de directive de
précompilation comme #if, il n'y a qu'un if. Celui-ci est alors parsé,
traité, évalué comme tous les autres if du code. L'une des solutions
consistent donc à voir 2 includes différents, l'un DEBUG et l'autre RELEASE
et de jongler entre les 2. Ça peut donner du code copié-collé à l'arrache,
des choses horribles :). Donc le plus simple c'est de s'armer d'un
débogueur, d'une bonne conception et d'un encodeur pour optimiser ce qui ne
peut l'être sans encodeur. Zend Encoder prend ton code, élimine
automatiquement tous ces ifs inutiles vu que DEBUG est à FALSE et tu te
retrouves donc avec une application 100% DEBUG ou 100% RELEASE.
Sinon comme te la dit Guillaume il faut regarder tes boucles critiques. Un
bon outil, le profiler, je te conseille d'essayer celui de Zend. Il y a
aussi phpEd, à essayer je n'ai pas encore eu le temps. J'ai été déçu par
Zend alors je vais voir du côté de NuSphere...
En C++ on faisait #define DEBUG ou #define RELEASE Puis #ifdef DEBUG... code DEBUG sinon... code RELEASE
En PHP, sans encodeur, il faut voir qu'il n'y a pas de directive de précompilation comme #if, il n'y a qu'un if. Celui-ci est alors parsé, traité, évalué comme tous les autres if du code. L'une des solutions consistent donc à voir 2 includes différents, l'un DEBUG et l'autre RELEASE et de jongler entre les 2. Ça peut donner du code copié-collé à l'arrache, des choses horribles :). Donc le plus simple c'est de s'armer d'un débogueur, d'une bonne conception et d'un encodeur pour optimiser ce qui ne peut l'être sans encodeur. Zend Encoder prend ton code, élimine automatiquement tous ces ifs inutiles vu que DEBUG est à FALSE et tu te retrouves donc avec une application 100% DEBUG ou 100% RELEASE.
Sinon comme te la dit Guillaume il faut regarder tes boucles critiques. Un bon outil, le profiler, je te conseille d'essayer celui de Zend. Il y a aussi phpEd, à essayer je n'ai pas encore eu le temps. J'ai été déçu par Zend alors je vais voir du côté de NuSphere...
