j'ai une classe implémentant le pattern factory et celle-ci sait créer
un nombre important d'objets à la complexité variable.
Pour inclure le code des classe d'objet produits, j'ai le choix entre :
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et
30 require_once), ce qui peut être consommateur au niveau i/o car des
classes d'objets complexe ont elles-même leur lot d'inclusion, ou
2) de faire l'appel à require_once dans le corps de la méthode.
La 1ère solution est plus maintenable à mon avis (une habitude
java/python ... pas taper!), mais du coup j'ai peur pour les
performances (d'où ce post). D'un autre coté, avec les caches présents à
tous les étages du système, ce temps est-il négligeable ? les
optimiseurs php connaissent-ils ce genre d'optimisation ?
Pour inclure le code des classe d'objet produits, j'ai le choix entre :
1) tout inclure au début du fichier 2) de faire l'appel à require_once dans le corps de la méthode.
Salut, suivant la convention de nommage de tes classes, il me semble qu'il y en a une deuxieme solution et demi : __autoload()
(et demi, parceque ca fait appel a require_once quand meme:)
http://fr.php.net/class_exists
A ++
John GALLET
Bonjour,
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et 30 require_once), Ok.
ce qui peut être consommateur au niveau i/o Les i/o encore, on s'en fout, c'est surtout le parsing par le moteur zend
qui prendra du temps (probablement néligeable par rapport à d'autres temps d'accès optimisables, mais à la longue lourds quand même).
2) de faire l'appel à require_once dans le corps de la méthode. En PHP3, c'est sans hésiter la méthode à utiliser avec include()
justement. Cf la FAQ de ce forum. En PHP4, on s'en tape, tout sera parsé de toutes façons.
D'un autre coté, avec les caches présents à tous les étages du système, ce temps est-il négligeable ? Dans ta configuration, il n'y a qu'un seul cache : le cache file system de
l'Operating System. A chaque requête HTTP, il y aura de nouveau parsing de tous les fichiers inclus, qui eux même seront lus dans le cache FS de l'OS ou sur disque.
optimiseurs php connaissent-ils ce genre d'optimisation ?
Qui dit optimisateur dit surtout cache d'opcode, et génération de l'équivalent de bytecode java donc.
Ca tombe bien, c'est justement le chapitre 15 de la FAQ de ce forum http://faqfclphp.free.fr/ que j'ai ajouté il y a moins d'une semaine.
a++; JG
Bonjour,
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et
30 require_once),
Ok.
ce qui peut être consommateur au niveau i/o
Les i/o encore, on s'en fout, c'est surtout le parsing par le moteur zend
qui prendra du temps (probablement néligeable par rapport à d'autres temps
d'accès optimisables, mais à la longue lourds quand même).
2) de faire l'appel à require_once dans le corps de la méthode.
En PHP3, c'est sans hésiter la méthode à utiliser avec include()
justement. Cf la FAQ de ce forum.
En PHP4, on s'en tape, tout sera parsé de toutes façons.
D'un autre coté, avec les caches présents à
tous les étages du système, ce temps est-il négligeable ?
Dans ta configuration, il n'y a qu'un seul cache : le cache file system de
l'Operating System. A chaque requête HTTP, il y aura de nouveau parsing de
tous les fichiers inclus, qui eux même seront lus dans le cache FS de
l'OS ou sur disque.
optimiseurs php connaissent-ils ce genre d'optimisation ?
Qui dit optimisateur dit surtout cache d'opcode, et génération de
l'équivalent de bytecode java donc.
Ca tombe bien, c'est justement le chapitre 15 de la FAQ de ce forum
http://faqfclphp.free.fr/ que j'ai ajouté il y a moins d'une semaine.
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et 30 require_once), Ok.
ce qui peut être consommateur au niveau i/o Les i/o encore, on s'en fout, c'est surtout le parsing par le moteur zend
qui prendra du temps (probablement néligeable par rapport à d'autres temps d'accès optimisables, mais à la longue lourds quand même).
2) de faire l'appel à require_once dans le corps de la méthode. En PHP3, c'est sans hésiter la méthode à utiliser avec include()
justement. Cf la FAQ de ce forum. En PHP4, on s'en tape, tout sera parsé de toutes façons.
D'un autre coté, avec les caches présents à tous les étages du système, ce temps est-il négligeable ? Dans ta configuration, il n'y a qu'un seul cache : le cache file system de
l'Operating System. A chaque requête HTTP, il y aura de nouveau parsing de tous les fichiers inclus, qui eux même seront lus dans le cache FS de l'OS ou sur disque.
optimiseurs php connaissent-ils ce genre d'optimisation ?
Qui dit optimisateur dit surtout cache d'opcode, et génération de l'équivalent de bytecode java donc.
Ca tombe bien, c'est justement le chapitre 15 de la FAQ de ce forum http://faqfclphp.free.fr/ que j'ai ajouté il y a moins d'une semaine.
a++; JG
ftc
2) de faire l'appel à require_once dans le corps de la méthode.
En PHP3, c'est sans hésiter la méthode à utiliser avec include() justement. Cf la FAQ de ce forum. En PHP4, on s'en tape, tout sera parsé de toutes façons.
Je n'en suis pas si sûr.
Prenons deux fichier: main.php <?php function test() { require_once( 'toinlude.php' ); } ?>
Second fichier: toinclude.php <?php echo 'Hello' $e = 1; ?>
Le second fichier va provoquer une erreur de parsing, or lorsqu'on appelle main.php, aucune erreur de parsing n'est engendrée, toinclude.php ne semble donc pas être parsé.
Par contre si on fait un appel à test() dans main.php, on a bel et bien une erreur de parsing.
2) de faire l'appel à require_once dans le corps de la méthode.
En PHP3, c'est sans hésiter la méthode à utiliser avec include()
justement. Cf la FAQ de ce forum.
En PHP4, on s'en tape, tout sera parsé de toutes façons.
Je n'en suis pas si sûr.
Prenons deux fichier: main.php
<?php
function test() {
require_once( 'toinlude.php' );
}
?>
Second fichier: toinclude.php
<?php
echo 'Hello'
$e = 1;
?>
Le second fichier va provoquer une erreur de parsing, or lorsqu'on
appelle main.php, aucune erreur de parsing n'est engendrée,
toinclude.php ne semble donc pas être parsé.
Par contre si on fait un appel à test() dans main.php, on a bel et bien
une erreur de parsing.
2) de faire l'appel à require_once dans le corps de la méthode.
En PHP3, c'est sans hésiter la méthode à utiliser avec include() justement. Cf la FAQ de ce forum. En PHP4, on s'en tape, tout sera parsé de toutes façons.
Je n'en suis pas si sûr.
Prenons deux fichier: main.php <?php function test() { require_once( 'toinlude.php' ); } ?>
Second fichier: toinclude.php <?php echo 'Hello' $e = 1; ?>
Le second fichier va provoquer une erreur de parsing, or lorsqu'on appelle main.php, aucune erreur de parsing n'est engendrée, toinclude.php ne semble donc pas être parsé.
Par contre si on fait un appel à test() dans main.php, on a bel et bien une erreur de parsing.
ftc
En complément à mon post précedent:
Tiré de la doc: Avant PHP 4.0.2, ceci s'appliquait : require() tentait de lire le fichier cible, même si les lignes n'étaient pas utilisées. Une condition if n'avait aucun effet sur require().
J'en déduis que maintenant, si le code ou se trouve le require n'est pas exécuté, le fichier ne sera pas inclus.
En complément à mon post précedent:
Tiré de la doc:
Avant PHP 4.0.2, ceci s'appliquait : require() tentait de lire le
fichier cible, même si les lignes n'étaient pas utilisées. Une condition
if n'avait aucun effet sur require().
J'en déduis que maintenant, si le code ou se trouve le require n'est pas
exécuté, le fichier ne sera pas inclus.
Tiré de la doc: Avant PHP 4.0.2, ceci s'appliquait : require() tentait de lire le fichier cible, même si les lignes n'étaient pas utilisées. Une condition if n'avait aucun effet sur require().
J'en déduis que maintenant, si le code ou se trouve le require n'est pas exécuté, le fichier ne sera pas inclus.
John GALLET
J'en déduis que maintenant, si le code ou se trouve le require n'est pas exécuté, le fichier ne sera pas inclus.
Oui ça c'est certain, il suffit d'un test d'une seule ligne :
En revanche, j'ai pas dû comprendre ce que voulait dire l'auteur de la question quant à l'emplacemement où il voulait mettre son require().
JG
Thierry Boudet
On 2005-07-07, Francois Girault wrote:
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et 30 require_once), ce qui peut être consommateur au niveau i/o car des classes d'objets complexe ont elles-même leur lot d'inclusion, ou
Effectivement. J'ai souvenir d'une application codée par des névrosés de la prog modulaire, qui définissaient une demi douzaine de chemins de recherche pour les includes. Alors forcément, à pleine charge, l'Apache était tout mou: plus de 400 stat/open rien que pour tout ces includes...
-- "Les calculs avec l'ordinateur, je les vérifies toujours avec la calculatrice : des fois que le fils il m'ait foutu une vérole, tu crois que le percepteur il me la foutrait pas, l'amende ?"
On 2005-07-07, Francois Girault wrote:
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et
30 require_once), ce qui peut être consommateur au niveau i/o car des
classes d'objets complexe ont elles-même leur lot d'inclusion, ou
Effectivement. J'ai souvenir d'une application codée par des
névrosés de la prog modulaire, qui définissaient une demi
douzaine de chemins de recherche pour les includes. Alors
forcément, à pleine charge, l'Apache était tout mou: plus
de 400 stat/open rien que pour tout ces includes...
--
"Les calculs avec l'ordinateur, je les vérifies toujours avec la
calculatrice : des fois que le fils il m'ait foutu une vérole, tu
crois que le percepteur il me la foutrait pas, l'amende ?"
1) tout inclure au début du fichier (ce qui pourrait faire entre 20 et 30 require_once), ce qui peut être consommateur au niveau i/o car des classes d'objets complexe ont elles-même leur lot d'inclusion, ou
Effectivement. J'ai souvenir d'une application codée par des névrosés de la prog modulaire, qui définissaient une demi douzaine de chemins de recherche pour les includes. Alors forcément, à pleine charge, l'Apache était tout mou: plus de 400 stat/open rien que pour tout ces includes...
-- "Les calculs avec l'ordinateur, je les vérifies toujours avec la calculatrice : des fois que le fils il m'ait foutu une vérole, tu crois que le percepteur il me la foutrait pas, l'amende ?"
