Friday afternoon toying: eZ Components as phar
PHP 5.3 will have a new cool feature: phar . A phar is to PHP what a jar is to Java. I spent a little time to see how easy it would be to make our latest eZ Components release into a workable phar.
First of all, a phar can be build from a directory structure with a few functions only:
<?php
$phar = new Phar(
'ezcomponents-2008.1.phar', 0,
'ezcomponents-2008.1.phar' );
$phar->buildFromDirectory(
dirname(__FILE__) . '/ezcomponents-2008.1',
'/\.php$/');
$phar->compressFiles( Phar::GZ );
$phar->stopBuffering();
?>
This build script will create a phar from the directory contents in "ezcomponents-2008.1", but only include the PHP files (See http://php.net/phar.buildfromdirectory). We compress all the files and with stopBuffering we write the file to disk. With the following code, we can now use the phar in our application:
require 'ezcomponents-2008.1.phar';
It is also possible to run a bit of code when including the phar. You do this, by adding a stub to the phar. To do so, we include the following code just before the compressFiles() call:
$stub = <<<ENDSTUB <?php Phar::mapPhar( 'ezcomponents-2008.1.phar' ); require 'phar://ezcomponents-2008.1.phar/Base/src/base.php'; spl_autoload_register( array( 'ezcBase', 'autoload' ) ); __HALT_COMPILER(); ENDSTUB; $phar->setStub( $stub );
After we re-create the phar with "php -dphar.readonly=0 build.php". The new phar once required will now setup the autoload mechanism of the eZ Components. The following script demonstrates that it actually works:
<?php
require 'ezcomponents-2008.1.phar';
$f = ezcFeed::parse( 'http://derickrethans.nl/rss.xml' );
foreach ( $f->item as $item )
{
echo $item->title, "\n";
}
?>
Conclusion: phar is cool!
Comments
As phar as I can see: Quite cool! :)
Inspired by your experiment, I tried Phar on PHPUnit: http://phpfi.com/327410
Good stuff :-)
Nice inspiration, works for PHP_Depend like a charm :-)
Are there any speed penalties?
This is interesting, and I'm betting is has a number of great uses. However this does add overhead. No matter how impressive the benchmarks are there will be overhead. If there is none I would be amazed, and would have to look into that closely.
I need every single clock cycle on my servers to serve requests as quickly as I can using as few resources as I can. So this is not for me. Plus, I'm not looking for easy of installation, since I don't have a problem unzipping or untarring a file.
But now we have one more custom archive format. And like jar it can be executed directly. I always thought jar(aka zip) was created because disk driver were $1,000 per 1GB at the time. But, anyways I'm not trying to save disk space, since PHP uses next to nothing. I'm not distributing to outside customers. And I need speed, not file system abstraction. Does this really come down to an executable "diskdoubler"?
Clearly this is not for my situation.
Where is it good? Distributing applications to people who have trouble with unzip or tar or WinZip for that matter. I guess and install programmer would have solved that, but no matter. This person would also not need to be concerned about performance, at least not on the same level I am. And they wouldn't mind the tiny bit of abstraction from file system.
Does that mean it's good for the small timers with not much traffic who cannot install some PHP files? Or is it a time saver, at the expense of performance?
Sum:
1 step forward, and 2 steps back?
Or
If it ain't broke, fix it 'til is is?
Or
Java-ism?
It's a dandy util, who's place in the fast paced web services world is yet to be determined.
@James, take a look at http://marc.info/?l=php-internals&m=121394601217048&w=2
Actually there may benefit as there are much less file input/output operations within a library.
I've tried something different, dynamically saturating a Phar inside the autoload function. After a few requests, all autoload attempts will be directly "answered" by the phar file. I've not benchmarked that yet, but the subjective speed improvement is tremendous since the number of i/o calls is reduced next to nothing.
I've tested Phar on my framework. Memory usage was greater when using the phar'ed version, and the performance difference was negligible... hopefully PHP 5.4 brings some enhancements to Phar.
Shortlink
This article has a short URL available: https://drck.me/fatecap-6dl