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.
Life Line
Updated an information and a bench
Created 2 benches
Created 4 picnic_tables, a bench, and a fitness_station; Updated a pub and a sport club
Created 2 benches and 2 waste_baskets; Updated 4 benches, a bus_stop, and a cafe; Confirmed a dentist
Created 3 waste_baskets, 2 main entrances, and a bench; Deleted a cycle_barrier, a bench, and a waste_basket
Created an information; Updated a waste_basket and a bench
Updated 2 waste_baskets and a bench
Created 3 benches
Created a waste_basket; Updated 2 benches and a tree
I walked 3.5km in 35m31s
Created a main entrance and a home entrance
Created an entrance
Updated a house building
Created an entrance
I walked 5.8km in 1h15m06s
I've just finished reading "A Cheese-Monger's Tour de France", by Ned Palmer.
Now I want to try many of those! 🧀
#books #BookList2026 #bookstodon #WorldBookDay
I'm thrilled to announce that I'll be speaking at the 23rd edition of #phpday, the international PHP conference in Italy, organised by @grusp.
I’ll be presenting a talk titled: "Better Debugging With Xdebug".
It's in Verona, Italy, on May 14-15th 2026.
You can use my speaker’s discount code "speaker_10OFF" for 10% off at https://www.phpday.it/tickets/?utm_medium=organic&utm_source=linkedin&utm_campaign=post-speaker
I walked 5.5km in 1h11m00s
I walked 1.1km in 9m37s
Merged pull request #1066
PHP 8.6: Changes to opcache optimisations wrt function arguments
I walked 10.5km in 1h49m54s
Fixed building type
Fixed addresses and building type
Updated a bus_stop, a waste_basket, and a bench
Shortlink
This article has a short URL available: https://drck.me/fatecap-6dl