Question

I’m currently experimenting with an extension mechanism for my framework. Each module consists of at least one PHP file (defining a single class) and an XSL stylesheet but potentially several other files could be involved so I immediately thought of using Phars.

Everything’s playing nicely together but I noticed if I didn’t use createDefaultStub() and instead constructed the Phar as in the following snippet then the result is a quarter of the size — and is smaller than the compressed version.

$phar = new Phar('Example.phar', 0, 'Example.phar');
$phar->buildFromDirectory(__DIR__ . '/src');
$phar->setStub('<?php __HALT_COMPILER();');
$phar->setSignatureAlgorithm(Phar::SHA256);
$phar->compress(Phar::GZ);

Example file sizes:

8799 14 Dec 09:37 ExampleCog.phar (using createDefaultStub())
2143 14 Dec 10:08 ExampleCog.phar (using __HALT_COMPILER())
3373 14 Dec 10:08 ExampleCog.phar.gz (consistent with either method)

The Phar will simply be used to keep module-specific files bundled together and will be included in a framework — running standalone wouldn’t make any sense in this context. I guess my question is, what am I missing out on — if anything — with using the minimal stub code? And why is the compressed version always the same size?

Answer 1

I guess my question is, what am I missing out on — if anything — with using the minimal stub code?

In the file format documentation, the default stub is described as:

The default stub for phar-based Phar archives contains approximately 7k of code to extract the contents of the phar and execute them.

It then points to Phar::createDefaultStub, which says:

This method provides a simple and easy method to create a stub that will run a startup file from the phar archive. In addition, different files can be specified for running the phar archive from the command line versus through a web server. The loader stub also calls Phar::interceptFileFuncs() to allow easy bundling of a PHP application that accesses the file system. If the phar extension is not present, the loader stub will extract the phar archive to a temporary directory and then operate on the files. A shutdown function erases the temporary files on exit.

Emphasis added, as that’s the reason the default stub is so large. If you can assume that you’ll always operate under PHP 5.3 or later, you probably don’t need the default stub and can stick with the minimal __HALT_COMPILER

And why is the compressed version always the same size?

Diving once again into the file format documentation, there’s a comparison between archive formats, which explains that Phar performs both per-file and whole-archive compression. It’s likely that you’re seeing similar compression sizes because gzip can’t compress the data any further. This is speculation.