I just went accross an interesting article about which of « print » or « echo » we should use in PHP.

The author has benchmarked the two solutions (though the data are certainly a bit old) shows that, although there is not much difference between the two, echo seems to be more efficient.

Great, I believe you.

Echo multiple statements / arguments vs. Concatenation

But at the end of the article, the author also suggest to use multiple parameters given to one echo statement instead of concatenation because concatenation is slow… bla bla…

As I have always been using concatenation (did not even know echo could take multiple arguments) and I never had any performance issue, I decided to check that and make a benchmark: echo 100,000 times two concatenated strings and do the same thing with two parameters and two echos statements…

The benchmark was clear: concatenation IS FASTER than the two other solutions.

String caching? Making a more relevant benchmark

As it appeared a bit weird to me, having been doing Java / C# mostly recently (with their slow concatenation that recreated a new object blabla), I thought « maybe the PHP VM is caching the result of the concatenated string, thus the benchmark is not relevant ».

OK, let’s check with a counter-possible-caching benchmark then:

$t0 = microtime(true);

define("MAX", 2000000);
File_put_ConTents("echobench._log", "");
function _log($str)
{
	File_put_ConTents("echobench._log", file_get_contents("echobench._log") . $str);
}

// Generating a bunch of string to concatenate to avoid PHP VM-caching
$strs = array();
for ($i=0; $i < MAX+1; $i++) { 
	$m = mt_rand(0, 200);
	$strs[$i] = '';
	for ($j=0; $j < $m; $j++) { 
		$strs[$i] .= chr(mt_rand(0, 255));
	}
}

// Loop where string concatenation caching is possible :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" . "World! 
";
}
$t2 = microtime(true);
_log("Concatenation, cached: " . ($t2-$t1) . "s\n");

// Loop where is is not :
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i] . $strs[$i + 1];
}
$t2 = microtime(true);
_log("Concatenation, not cached: " . ($t2-$t1) . "s\n");

// Other ways to display stuff, with and without caching possible each time:
$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i];
	echo $strs[$i + 1];
}
$t2 = microtime(true);
_log("Two echos, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "
";
	echo "World" , "
";
}
$t2 = microtime(true);
_log("Two echos, cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo $strs[$i], $strs[$i + 1];;
}
$t2 = microtime(true);
_log("Two parameters, not cached: " . ($t2-$t1) . "s\n");

$t1 = microtime(true);
for ($i=0; $i < MAX; $i++) { 
	echo "Hello" , "World!" , "
";
}
$t2 = microtime(true);
_log("Two parameters, cached: " . ($t2-$t1) . "s\n");

$t3 = microtime(true);

_log("Total benchmark time: " . ($t3-$t0)."\n");

I generated random strings at the beginning of the script. And I concatenate them after, in the loop. Thus, there is not even once the same concatenation happening, thus, no possible caching or whatever.

The benchmarked has been run on a 1.6GHz Atom processor, with the following command:

sudo nice -n -19 php -q echobanchmark.php > /dev/null

So the process was the most prioritized one on the OS and then there is no reason for any interference between the loops (moreover, the system was idle during the test (and there are 3 other virtual processors for doing whatever work the OS would need to do).

And do you know the result?

Here it goes:

Concatenation, cached: 7.4381861686707s
Concatenation, not cached: 9.9010219573975s
Two echos, not cached: 10.4353120327s
Two echos, cached: 14.883654117584s
Two parameters, not cached: 10.179102897644s
Two parameters, cached: 11.904446840286s
Total benchmark time: 928.97792601585

Conclusion: Concatenation is fast, very fast. It is rougly 30% faster than using the two parameters for echo (26.9268987% exactly) and roughly 30% faster than two echo statements as well (28.720999% exactly) and

The other conclusion here is that PHP does not seem to be caching strings very well. Both the two-parameters and two-statements echo loops are much slower when using a fresh new string and much faster when using something from the previously generated array. The difference between cached / non-cached loop for the concatenation loop is also not that impressive if we observe that my « not cached » loop is using strings of random length that can go until 200 chars whereas the « cached » one is a very short string (so the difference of 2 seconds is certainly also due to the difference in length of the strings).

If you have any suggestion to improve the benchmark, feel free to post a comment.

Depuis le temps que je grognais contre le fait qu’en C ou même en Pascal on peut accéder au caractère X d’une chaine de caractère en faisant machaine[X] et qu’en PHP on peut pas… Et depuis le temps que j’utilisais à la place substr($str, X-1, X) !!!!

Eh ben en fait, suffit de faire ça :

$mastring{X}

Fuck, j’m’en veux là.

Bon ben du coup c’est la révolution : je sais faire ça et en plus c’est le deuxième billet super court que je fais en 2 jours.

Désolé pour les non-geeks qui auront rien compris à ce post, il faut bien des fois aussi hein, regardez, moi je comprends rien aux posts qui sont postés là-bas eh ben tant pis, je me dis que c’est normal !

As usual, for international readers, the english version is below, at the end of the French version

Alors, on va encore m’accuser de publier que des billets geeks, et court pour celui-ci en plus, mais c’est tellement galère à chercher sur le net, que je ne peux m’empêcher de partager cette astuce avec vous

Passons aux choses intéressantes : Il peut être intéressant, voire indispensable (et ça vous intéressera majoritairement dans le cas où c’est indispensable, n’est-ce pas ) de pouvoir utiliser une vieille version de autoconf, notamment la fameuse 2.13, à la place votre super version hyper à jour utilisée par votre système GNU/Linux. Cependant, la question toute bête : bordel comment on fait pour dire à buildconf d’utiliser une autre version que celle par défaut du système ?

Eh bien, si vous avez passé une heure à chercher sur internet avant d’atterrir ici, vous allez être peut-être un peu déçu par la simplicité de la chose, mais bon, on n’échappe pas aux lois de Murphy ! :

export PHP_AUTOCONF=`which autoconf-2.13`

Note : ceci est l’exemple pour la compilation de PHP, pour la compilation d’un autre programme cela ressemblera très certainement à cela, je ne peux cependant pas donner de généralité !

Voilà c’est fini. Il suffit de taper cela dans votre console juste avant d’exécuter la commande « ./builconf » (ou généralement « ./buildconf –force » mais peu importe). Attention, cependant, vous devez taper cette commande et celle du buildconf dans la même console, évidemment.

J’espère que vous vous sentez soulagés Notamment si vous étiez en train d’essayer d’installer…humm… php depuis les sources ?

Merci à MaGeekGuy pour l’astuce

————————————————————————————————-

Well, I’m going to be again accused to publish only geek articles, and moreover, short, for this one, but it’s such a real pain to find that on the Internet, then I can’t resist to share it with you folks

Interesting things now : It can be useful, not to say essential (and it will interest you more in the case it’s essential, won’t it ) to be able to use an old version of autoconf, for exemple the famous 2.13, instead of your state-of-the-heart version used by default by your GNU/Linux operating system. However, what a stupid question : how the hell do you explain to buildconf that it must use an older version instead of the default one ?

Well, if you’ve just spent about an hour searching on the Internet before coming here, you may be a bit disapointed by the simplicity of the solution. But, after all, no one escape from Murphy’s laws ! :

export PHP_AUTOCONF=`which autoconf-2.13`

NB : this is an example for PHP compilation, for other soft compilation it will certainly be much like that, but I can’t exhibate a general case here.

Voilà, it’s over ! You now only need to type that in your shell just before the « ./buildconf » command (or more often « ./buildconf –force » but it doesn’t really matter). Beware, however, you must type this command in the same shell as the buildconf one, obviously.

I hope you feel distressed Specifically if you were trying to install…well… php from the sources ?

Thanks to MaGeekGuy for this tip .

L’astuce est toute simple, elle consiste à tenter d’ouvrir le fichier, avec une fonction qui elle, prend en charge le HTTP :

function FichierDistantExiste($url) {
   if(!@fopen($url, 'r')) return false;
   else return true;
}

Ce fut bref, mais j’espère que cela vous sera utile

Attention par contre, sauf erreur de ma part certaines configurations PHP (notamment sur des mutualisés évidemment, mais pas tous hein) empêchent fopen() d’utiliser le HTTP. Dans ce cas, on serait bien tenté d’utiliser la fonction file_get_contents() sauf qu’en fait ce n’est qu’une espèce de raccourci pour les fonction fopen(), fgets() et fclose() les un après les autres. Donc si l’un est bridé l’autre devrait l’être aussi. À vous de tester, on ne sait jamais.

D’ailleurs, au passage, comme je suis un gentil Troll, je vous l’ai traduite

// Récupérer la date de dernière modification d'un fichier distant (la fonction retourne un timestamp unix, cf. http://wiki.pcinfo-web.com/timestamp )
function RecupDateModifDistant( $uri )
{
// default
$unixtime = 0;
$fp = fopen( $uri, "r" );
if( !$fp ) {return;}

$MetaData = stream_get_meta_data( $fp );

foreach( $MetaData['wrapper_data'] as $response )
{
// Dans le cas d'une redirection vers une autre page / un autre fichier
if( substr( strtolower($response), 0, 10 ) == 'location: ' )
{
$newUri = substr( $response, 10 );
fclose( $fp );
return RecupDateModifDistant( $newUri );
}
// Dans le cas où on a bien l'en-tête "last-modified"
elseif( substr( strtolower($response), 0, 15 ) == 'last-modified: ' )
{
$unixtime = strtotime( substr($response, 15) );
break;
}
}
fclose( $fp );
return $unixtime;
}

Voilà, pour toute demande d’explication du code, les commentaires sont là pour ça, ils vous attendent pour vous faire des calins ! (gratuit !)

Tout d’abord, petit retour rapide sur le fonctionnement de DTC :

DTC crée un utilisateur « dtc » et un groupe « dtcgrp » avec lesquels il fait la plupart de ce qu’il a à faire. Ainsi le ftp est géré par l’utilisateur DTC, les connexions en SSH également (mais justement il y a de sacrés bugs là-dessus), les connexions imap, smtp, etc… etc… et également les connexions HTTP, et donc les lancements d’Apache2 !

Concrètement, DTC est fait pour gérer un serveur dédié et donc proposer divers hébergements à divers sites.

Il crée toute une arborescence à laquelle on adhère ou non mais qui a le mérite d’être relativement claire et facile à utiliser et retenir.

Tous les fichiers de tous les sites appartiennent ainsi à un seul et unique couple user/groupe : dtc/dtcgrp.

DTC utilise énormément le principe plus ou moins bon des chroot pour lancer ses scripts de manière à les « endiguer » et qu’ils n’aillent pas faire n’importe quoi, particulièrement sur les fichiers appartenant à DTC sur le serveur.

Cependant DTC n’a pas prévu une chose… c’est l’utilisation de la commande shell_exec() de PHP (PHP 5 notamment, je ne sais pas pour le 4).

Par défaut, le safe_mode étant activé avec PHP, la commande shell_exec est quasiment inutilisable.

Cependant, si par malheur vous désactiver le safe_mode sur un domaine particulier… catastrophe ! Vous venez d’autoriser la personne qui s’occupe du site de ce domaine, à faire n’importe quoi sur le serveur (enfin sauf tâches d’administration (root) ).

Non seulement parce-qu’elle peut maintenant utiliser shell_exec() pour effectuer des actions au niveau de l’utilisateur dtc, mais surtout parce-que, même si certaines commandes sont bridées, shell_exec() permet d’utiliser la commande crontab.

Or, crontab permet de définir des tâches cron (je vous renvoie à Google si vous ne savez pas ce que c’est : cron est un gestionnaire de tâches planifiées). Or, quand cron lance la tâche, qu’elle qu’elle soit, elle est lancée au niveau de l’utilisateur auquel le cron appartient.

Concrètement si je fais ceci :

file_put_contents('temp.cron', '* * * * * cp /chemin/dun/autre/site/includes/passwordsdatabase.inc.php /chemin/de/mon/site/');
shell_exec('crontab -u dtc /chemin/de/mon/site/temp.cron');

Hop, plus qu’à attendre une minute et j’aurais dans mes fichiers… les mots de passe de la base de données de mon voisin sur le serveur.

C’est un problème très important, donc, et je ne sais pas du tout comment DTC compte gérer les choses dans le futur puisque le safe_mode est amené à disparaîre : déjà considéré comme obsolète dans PHP 5, il sera définitivement supprimé avec PHP 6.

Il est possible que – comme souvent en informatique – GPLHost (éditeur de DTC) dise simplement « Logiciel compatible uniquement avec les versions suivantes de PHP : …. ».

En attendant, vous êtes donc maintenant au courant : NE DESACTIVEZ PAS LE SAFE_MODE PHP SI VOUS UTILISEZ DTC AVEC PLUSIEURS SITES DIFFERENTS.

Cependant, il y a certainement une alternative à cela : j’imagine bien que PHP ou Apache ont la possibilité d’interdire certaines commandes. Ainsi lorsque vous désactivez le safe_mode, pensez à interdire l’utilisation de la commande shell_exec().

Voilà c’était le bulletin sécurité (en exclu !!) du Troll