Friday afternoon toying: eZ Components as phar

Friday, June 27th 2008, 16:15 CEST

Skien, Norway

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!

Shortlink

This article has a short URL available: https://drck.me/fatecap-6dl

Comments

Tobias Schlitt

Friday, June 27th 2008, 15:24 UTC

As phar as I can see: Quite cool! :)

Sebastian Bergmann

Friday, June 27th 2008, 16:00 UTC

Inspired by your experiment, I tried Phar on PHPUnit: http://phpfi.com/327410

Good stuff :-)

Manuel Pichler

Friday, June 27th 2008, 20:57 UTC

Nice inspiration, works for PHP_Depend like a charm :-)

Max Horvath

Wednesday, July 16th 2008, 07:27 UTC

Are there any speed penalties?

James Dornan

Thursday, August 14th 2008, 19:16 UTC

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?

If it ain't broke, fix it 'til is is?

Java-ism?

It's a dandy util, who's place in the fast paced web services world is yet to be determined.

Przemek Sobstel

Wednesday, September 3rd 2008, 06:54 UTC

@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.

Markus Nix

Monday, July 5th 2010, 20:56 UTC

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.

Ted Wood

Sunday, December 18th 2011, 01:03 UTC

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.

Add Comment

Name:
Email:	Will not be posted. Please leave empty instead of filling in garbage though!
Comment:	Please follow the reStructured Text format. Do not use the comment form to report issues in software, use the relevant issue tracker. I will not answer them here.
	All comments are moderated