Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35014
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Wed, 30 Jan 2008 10:36:26 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <839813632.20080130103626@marcus-boerger.de>
To: Mike <ipso@snappymail.ca>
CC: Gregory Beaver <greg@chiaraquartet.net>, 
	internals Mailing List <internals@lists.php.net>
In-Reply-To: <1201638906.24165.109.camel@ipso.snappymail.ca>
References: <479E1152.50301@chiaraquartet.net> <1201638906.24165.109.camel@ipso.snappymail.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
From: helly@php.net (Marcus Boerger)

Hello Mike,

  not that I have any benchmarks. But I have one thing you might want to
know. You extract a phar and map it to the extracted folder. That is any
operation that would normally end up in the phar then ends up in direct file
access. Doing so would add a tiny overhead for loading the file only. That
is the pahr extension has to figure out that it is responsible for a file
and then modify the filename. This should not be measurable at all.

marcus

Tuesday, January 29, 2008, 9:35:06 PM, you 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.

> Thanks.

> On Mon, 2008-01-28 at 11:30 -0600, Gregory Beaver wrote:
>> Criticisms:
>> 
>>  * non-standard file format
>>  * limited introspection
>>  * no support for web-based applications
>>  * by default, phar archives require the phar extension to run
>>  * massive modification of php applications required to run them as a
>> phar archive
>>  * no caching of phar files in opcode caches
>>  * has write support in the extension
>> 




Best regards,
 Marcus