Je cherche le plus simple moyen pour rajouter le slash final d'une variable,
si le "/" est absent bien-sûr, avant de la passer sur fopen.
J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ampac
Dans news:bl66gp$ttv$, Mel. raconte :
Bonjour,
Je cherche le plus simple moyen pour rajouter le slash final d'une variable, si le "/" est absent bien-sûr, avant de la passer sur fopen. J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
if($mavar[strlen($mavar)-1]=="/")
ou mieux expression reguliere
if(!ereg("/$",$mavar) // non testé si ca marche pas essaye avec crochet ereg("[/]$",$mavar)
-- Ampac
Dans news:bl66gp$ttv$1@news-reader4.wanadoo.fr,
Mel. raconte :
Bonjour,
Je cherche le plus simple moyen pour rajouter le slash final d'une
variable, si le "/" est absent bien-sûr, avant de la passer sur fopen.
J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
if($mavar[strlen($mavar)-1]=="/")
ou mieux expression reguliere
if(!ereg("/$",$mavar)
// non testé si ca marche pas essaye avec crochet ereg("[/]$",$mavar)
Je cherche le plus simple moyen pour rajouter le slash final d'une variable, si le "/" est absent bien-sûr, avant de la passer sur fopen. J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
if($mavar[strlen($mavar)-1]=="/")
ou mieux expression reguliere
if(!ereg("/$",$mavar) // non testé si ca marche pas essaye avec crochet ereg("[/]$",$mavar)
-- Ampac
Guillaume Bouchard
Mel. wrote:
Je cherche le plus simple moyen pour rajouter le slash final d'une variable, si le "/" est absent bien-sûr, avant de la passer sur fopen. J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
Methode qui marche, alors pourquoi changer la methode. En l'occurence, elle fonctionne même plutot bien, si encore cela bouffais 200 % de cpu pendant 3 jours, tu pourais te poser cette question, mais là, l'interet est leger.
Bref, je ne voie pas d'autre solution qu'un test sur la chaine pour reperer le slashs et ajout si besion est. Cela te laisse toutes les fonctions de chaines dispos, mais bon, substr le fait tres bien, pourquoi s'en priver ?
-- Guillaume. Qui à definitivement perdu son titre de plus gros posteur ;o)
Mel. wrote:
Je cherche le plus simple moyen pour rajouter le slash final d'une variable,
si le "/" est absent bien-sûr, avant de la passer sur fopen.
J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
Methode qui marche, alors pourquoi changer la methode. En l'occurence,
elle fonctionne même plutot bien, si encore cela bouffais 200 % de cpu
pendant 3 jours, tu pourais te poser cette question, mais là, l'interet
est leger.
Bref, je ne voie pas d'autre solution qu'un test sur la chaine pour
reperer le slashs et ajout si besion est. Cela te laisse toutes les
fonctions de chaines dispos, mais bon, substr le fait tres bien,
pourquoi s'en priver ?
--
Guillaume.
Qui à definitivement perdu son titre de plus gros posteur ;o)
Je cherche le plus simple moyen pour rajouter le slash final d'une variable, si le "/" est absent bien-sûr, avant de la passer sur fopen. J'ai pensé à un if(substr, mais il y a peut-être plus "élégant" non ?
Methode qui marche, alors pourquoi changer la methode. En l'occurence, elle fonctionne même plutot bien, si encore cela bouffais 200 % de cpu pendant 3 jours, tu pourais te poser cette question, mais là, l'interet est leger.
Bref, je ne voie pas d'autre solution qu'un test sur la chaine pour reperer le slashs et ajout si besion est. Cela te laisse toutes les fonctions de chaines dispos, mais bon, substr le fait tres bien, pourquoi s'en priver ?
-- Guillaume. Qui à definitivement perdu son titre de plus gros posteur ;o)
Guillaume Bouchard
Ampac wrote:
if($mavar[strlen($mavar)-1]=="/")
Moué, enfin le substr fait la meme chose en moins de caracteres :)
if(substr($mavar,-1) != '/')
ou mieux expression reguliere
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
-- Guillaume. 2, le score remonte.
Ampac wrote:
if($mavar[strlen($mavar)-1]=="/")
Moué, enfin le substr fait la meme chose en moins de caracteres :)
if(substr($mavar,-1) != '/')
ou mieux expression reguliere
Coef Coef Coef (tm)
Les expressions regulieres c'est ma grand passion, mais n'empeche que
faux pas les utiliser quand elle ne le demande pas, c'est infiniement
plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
grave, mais faux pas prendre de mauvaises habitudes :)
Moué, enfin le substr fait la meme chose en moins de caracteres :)
if(substr($mavar,-1) != '/')
ou mieux expression reguliere
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
-- Guillaume. 2, le score remonte.
Thibaut Allender
"Guillaume Bouchard" wrote in message news:3f7704ee$0$2772$
ou mieux expression reguliere
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
c'est d'autant plus gonflé que je me faisais presque engueuler l'autre fois par ampac avec mes expressions regulieres ;)
-- + thibaut allender // web design + php dev + digital photo + http://www.capsule.org
"Guillaume Bouchard" <gobpower@free.fr> wrote in message
news:3f7704ee$0$2772$626a54ce@news.free.fr...
ou mieux expression reguliere
Coef Coef Coef (tm)
Les expressions regulieres c'est ma grand passion, mais n'empeche que
faux pas les utiliser quand elle ne le demande pas, c'est infiniement
plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
grave, mais faux pas prendre de mauvaises habitudes :)
c'est d'autant plus gonflé que je me faisais presque engueuler l'autre fois
par ampac avec mes expressions regulieres ;)
--
+ thibaut allender // web design + php dev + digital photo
+ http://www.capsule.org
"Guillaume Bouchard" wrote in message news:3f7704ee$0$2772$
ou mieux expression reguliere
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
c'est d'autant plus gonflé que je me faisais presque engueuler l'autre fois par ampac avec mes expressions regulieres ;)
-- + thibaut allender // web design + php dev + digital photo + http://www.capsule.org
Ampac
Dans news:3f7704ee$0$2772$, Guillaume Bouchard raconte :
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
Je partage completement tes avis. Je ne faisais qu'essayer de donner des facons d'obtenir le dernier carac d'une chaine puisque le monsieur demandait si il y avait d'autres manieres que le sempiternel substr. Il va de soi que le substr($machaine,-1) ici semble etre ce qu'il y a de meilleur en terme de perf et de simplicite d'ecriture.
-- Ampac
Dans news:3f7704ee$0$2772$626a54ce@news.free.fr,
Guillaume Bouchard raconte :
Coef Coef Coef (tm)
Les expressions regulieres c'est ma grand passion, mais n'empeche que
faux pas les utiliser quand elle ne le demande pas, c'est infiniement
plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
grave, mais faux pas prendre de mauvaises habitudes :)
Je partage completement tes avis.
Je ne faisais qu'essayer de donner des facons d'obtenir le dernier carac
d'une chaine puisque le monsieur demandait si il y avait d'autres manieres
que le sempiternel substr.
Il va de soi que le substr($machaine,-1) ici semble etre ce qu'il y a de
meilleur en terme de perf et de simplicite d'ecriture.
Dans news:3f7704ee$0$2772$, Guillaume Bouchard raconte :
Coef Coef Coef (tm) Les expressions regulieres c'est ma grand passion, mais n'empeche que faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien grave, mais faux pas prendre de mauvaises habitudes :)
Je partage completement tes avis. Je ne faisais qu'essayer de donner des facons d'obtenir le dernier carac d'une chaine puisque le monsieur demandait si il y avait d'autres manieres que le sempiternel substr. Il va de soi que le substr($machaine,-1) ici semble etre ce qu'il y a de meilleur en terme de perf et de simplicite d'ecriture.
-- Ampac
John GALLET
faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
Infiniment rien que ça.
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles CPU / le temps en ms qui vont/va être gagné en utilisant une fonction str_* à la place re ereg_* ? Est-ce qu'un jour vous allez enfin comprendre que ce genre de conneries n'apporte RIEN en perfs vis-à-vis des traitements qui prennent 20-50ms parce qu'ils sont codés en dépit du bon sens, des variables qui transitent 25 fois entre le client et le serveur alors que ça sert à rien (genre au hasard : header:location dans tous les coins comme des gorets) et autres erreurs majeures de conception ?
Vous regardez le problème par le petit bout de lorgnette les enfants, c'est comme savoir s'il faut utiliser des " ou des ' et des opérateurs de concaténation ou pas dans les strings, faut arrêter.
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup plus de temps et de ressources).
a++ JG
faux pas les utiliser quand elle ne le demande pas, c'est infiniement
plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
Infiniment rien que ça.
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles
CPU / le temps en ms qui vont/va être gagné en utilisant une fonction
str_* à la place re ereg_* ?
Est-ce qu'un jour vous allez enfin comprendre que ce genre de conneries
n'apporte RIEN en perfs vis-à-vis des traitements qui prennent 20-50ms
parce qu'ils sont codés en dépit du bon sens, des variables qui transitent
25 fois entre le client et le serveur alors que ça sert à rien (genre au
hasard : header:location dans tous les coins comme des gorets) et autres
erreurs majeures de conception ?
Vous regardez le problème par le petit bout de lorgnette les enfants,
c'est comme savoir s'il faut utiliser des " ou des ' et des opérateurs de
concaténation ou pas dans les strings, faut arrêter.
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en
reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup
plus de temps et de ressources).
faux pas les utiliser quand elle ne le demande pas, c'est infiniement plus bouffeur en ressources. Alors c'est clair que là c'est pas bien
Infiniment rien que ça.
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles CPU / le temps en ms qui vont/va être gagné en utilisant une fonction str_* à la place re ereg_* ? Est-ce qu'un jour vous allez enfin comprendre que ce genre de conneries n'apporte RIEN en perfs vis-à-vis des traitements qui prennent 20-50ms parce qu'ils sont codés en dépit du bon sens, des variables qui transitent 25 fois entre le client et le serveur alors que ça sert à rien (genre au hasard : header:location dans tous les coins comme des gorets) et autres erreurs majeures de conception ?
Vous regardez le problème par le petit bout de lorgnette les enfants, c'est comme savoir s'il faut utiliser des " ou des ' et des opérateurs de concaténation ou pas dans les strings, faut arrêter.
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup plus de temps et de ressources).
a++ JG
Thibaut Allender
"John GALLET" wrote in message news:
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles CPU / le temps en ms qui vont/va être gagné en utilisant une fonction str_* à la place re ereg_* ?
oui, je l'ai fait ici : news:3f760a38$0$27044$ ;)
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup plus de temps et de ressources).
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de code !
a+
"John GALLET" <john.gallet@wanadoo.fr> wrote in message
news:Pine.LNX.4.44.0309291631180.9133-100000@ns2261.ovh.net...
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles
CPU / le temps en ms qui vont/va être gagné en utilisant une fonction
str_* à la place re ereg_* ?
oui, je l'ai fait ici : news:3f760a38$0$27044$626a54ce@news.free.fr ;)
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en
reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup
plus de temps et de ressources).
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de
code !
Est-ce que quelqu'un peut prendre le temps de calculer le nombre de cycles CPU / le temps en ms qui vont/va être gagné en utilisant une fonction str_* à la place re ereg_* ?
oui, je l'ai fait ici : news:3f760a38$0$27044$ ;)
Quand on en sera tous à gagner des perfs sur ce genre de choses, on en reparlera. Pour le moment y'a plus important (i.e. qui prend beaucoup plus de temps et de ressources).
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de code !
a+
John GALLET
On 30 Sep 2003, Thibaut Allender wrote:
oui, je l'ai fait ici : news:3f760a38$0$27044$ ;) Oui et non : je parle du temps gagné par appel. Selon tes chiffres :
sur 100 000 operations, l'eregi() prend 5.6 sec sur un p2 350 (ce qui n'est pas tout recent), alors que strpos() prend 1.2 sec
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms Si on est pas dans une boucle de traitementde plus de 100 itérations ce n'est même aps mesurable.
donc strpos() est 4 a 5x plus rapide que eregi() Ce n'est pas seulement ainsi qu'il faut raisonner pour mesurer l'impact
sur le temps d'exécution d'un script. Même si c'est vrai par ailleurs.
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de code ! En plus. Mais on peut aussi perdre en lisibilité ;-)
Bref, ***a priori*** oui, ne mettez pas des regexp de trois lignes sur un traitement de 10 000 lignes si vous pouvez faire autrememnt mais surtout, faites un véritable test en essayant avec et sans regexp pour avoir le temps gagné réellement sur **chaque cas précis**.
a++ JG
On 30 Sep 2003, Thibaut Allender wrote:
oui, je l'ai fait ici : news:3f760a38$0$27044$626a54ce@news.free.fr ;)
Oui et non : je parle du temps gagné par appel. Selon tes chiffres :
sur 100 000 operations, l'eregi() prend 5.6 sec sur un p2 350 (ce qui
n'est pas tout recent), alors que strpos() prend 1.2 sec
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms
Si on est pas dans une boucle de traitementde plus de 100 itérations ce
n'est même aps mesurable.
donc strpos() est 4 a 5x plus rapide que eregi()
Ce n'est pas seulement ainsi qu'il faut raisonner pour mesurer l'impact
sur le temps d'exécution d'un script. Même si c'est vrai par ailleurs.
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de
code !
En plus. Mais on peut aussi perdre en lisibilité ;-)
Bref, ***a priori*** oui, ne mettez pas des regexp de trois lignes sur un
traitement de 10 000 lignes si vous pouvez faire autrememnt mais surtout,
faites un véritable test en essayant avec et sans regexp pour avoir le
temps gagné réellement sur **chaque cas précis**.
oui, je l'ai fait ici : news:3f760a38$0$27044$ ;) Oui et non : je parle du temps gagné par appel. Selon tes chiffres :
sur 100 000 operations, l'eregi() prend 5.6 sec sur un p2 350 (ce qui n'est pas tout recent), alors que strpos() prend 1.2 sec
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms Si on est pas dans une boucle de traitementde plus de 100 itérations ce n'est même aps mesurable.
donc strpos() est 4 a 5x plus rapide que eregi() Ce n'est pas seulement ainsi qu'il faut raisonner pour mesurer l'impact
sur le temps d'exécution d'un script. Même si c'est vrai par ailleurs.
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de code ! En plus. Mais on peut aussi perdre en lisibilité ;-)
Bref, ***a priori*** oui, ne mettez pas des regexp de trois lignes sur un traitement de 10 000 lignes si vous pouvez faire autrememnt mais surtout, faites un véritable test en essayant avec et sans regexp pour avoir le temps gagné réellement sur **chaque cas précis**.
a++ JG
Thibaut Allender
"John GALLET" wrote in message news:
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms Si on est pas dans une boucle de traitementde plus de 100 itérations ce n'est même aps mesurable.
oui, c'est ce que je disais dans le meme article, sur une seule operation, la difference est negligeable
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de
code ! En plus. Mais on peut aussi perdre en lisibilité ;-)
si le lecteur est le createur, ca doit pas trop poser de problemes ;)
a+
"John GALLET" <john.gallet@wanadoo.fr> wrote in message
news:Pine.LNX.4.44.0309301035410.14263-100000@ns2261.ovh.net...
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms
Si on est pas dans une boucle de traitementde plus de 100 itérations ce
n'est même aps mesurable.
oui, c'est ce que je disais dans le meme article, sur une seule operation,
la difference est negligeable
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes
de
code !
En plus. Mais on peut aussi perdre en lisibilité ;-)
si le lecteur est le createur, ca doit pas trop poser de problemes ;)
Donc on gagne sur un script : 5.6-1.2 / 100000 = 4.4e-05 sec soit 0.044 ms Si on est pas dans une boucle de traitementde plus de 100 itérations ce n'est même aps mesurable.
oui, c'est ce que je disais dans le meme article, sur une seule operation, la difference est negligeable
sans oublier qu'avec une regexp on peut parfois gagner pas mal de lignes de
code ! En plus. Mais on peut aussi perdre en lisibilité ;-)
si le lecteur est le createur, ca doit pas trop poser de problemes ;)
