Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35012
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error)
Message-ID: <479FC59E.7050706@chiaraquartet.net>
Date: Tue, 29 Jan 2008 18:32:30 -0600
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Mike <ipso@snappymail.ca>
CC: internals Mailing List <internals@lists.php.net>
References: <479E1152.50301@chiaraquartet.net> <1201638906.24165.109.camel@ipso.snappymail.ca>
In-Reply-To: <1201638906.24165.109.camel@ipso.snappymail.ca>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
From: greg@chiaraquartet.net (Gregory Beaver)

Mike wrote:
> Hi Gregory,
> 
> 	Do you have any benchmarks that compare the speed between trying to
> include/require files NOT in a phar archive, compared with calling
> include/require for files inside a phar archive?
> 
> I have a large PHP application with about 5000 PHP files and we make use
> of the __autoload() functionality and Smarty extensively, each page load
> probably includes between 5-100 files itself, so the speed of this
> operation is crucial. 
> 
> It would be great if we could bundle our entire application as a single
> phar archive, it would also make automatic in-place upgrades/roll-backs
> that much easier, but if the day-to-day operation takes a significant
> speed hit, it obviously won't be worth it.

Hi Mike,

I don't have any - I have been focusing 100% on correctness thus far.
Anecdotally, I couldn't perceive any difference in performance between
gzipped pharred phpMyAdmin and off-the-disk phpMyAdmin, but that is not
so useful :).  Based on the implementation, I suspect that an
uncompressed tar may be the fastest phar, with uncompressed phar without
a signature as a close second.  zip is slower simply because of the file
 format's design, but again I have not measured this to verify it.
Uncompressed tar files don't have any checksum beyond the 512 byte
header, which reduces processing of individual files.  Both phar and zip
do a crc32 on file contents to catch corruption, and zip file format has
redundant local/central headers for each file to further catch
corruption and make repair possible (although I have to admit I've never
had any success getting pkzip to repair a broken zip before).  phar has
a whole-file signature support, which replaces crc32 verification if
present, and zip does not (yet) have signature support.

However, a phpMyAdmin I pharred up a year or two again using a pure PHP
implementation of the phar wrapper (http://pear.php.net/PHP_Archive) was
noticeably slower, so I'm encouraged.

My game plan with pecl/phar at the moment is to finish fixing up the few
known remaining issues, finish the docs (the "creating phar" docs is
incomplete), and then profile.  I have also not yet tried it with APC to
see how that would work, and this is a high priority.  There are
definitely ways to cache the phar manifest, eliminating the need to
parse the file, I have not investigated this either, and this would in
fact be the largest speedup.

I already have a setup I've been using to debug the web front controller
which could be used to benchmark, but I wonder which application I
should use for a benchmark?  Any suggestions?  If anyone else has the
resources and time to do a benchmark comparison, this would be very
helpful to us poor time-strapped phar devs.

What needs comparison is the app on-disk, and the app in formats
uncompressed phar, uncompressed tar, zip, gzipped tar, bzipped tar,
gzipped phar, bzipped phar, zip compressed individually with deflate
(zlib), ...

It's quite a long list of possibilities.  Perhaps the most important is
uncompressed tar/uncompressed phar/on-disk.  This will showcase the
latency, and running these with APC is a priority, once we can verify
that APC actually caches as intended with phar.

Greg