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
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
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()
On Mon, 28 Jan 2008 11:30:58 -0600, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I have been working hard on pecl/phar to address several issues raised
> last May when it was first mentioned on the list, and would like to
> summarize where phar stands today with regards to those critic
Andi Gutmans wrote:
Hey Greg,
This looks very promising. Great to see that you took those feedbacks
and really attacked them leading to a huge improvement in phar (should I
say night and day :) I think you've really accomplished a lot in these
few months.
Are there any docs which describ
gt; Subject: [PHP-DEV] re-proposal of pecl/phar for inclusion in core
>
> Hi all,
>
> I have been working hard on pecl/phar to address several issues raised
> last May when it was first mentioned on the list, and would like to
> summarize where phar stands today with regards to tho
Pierre Joye wrote:
>>> for ext/zip, or zip64, but zip64 would also be trivial to add to phar,
>
> It is already implemented. We are working on portability issues.
> That's why I put the custom stream support as the top priority, it is
> the way to go to solve almost portability issues.
Which is?
On Jan 28, 2008 10:30 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > However I find your actual positions confusing and each mails bring
> > opposing arguments about the shared work between other archives
> > extension and phar. Can you clarify your view please?
>
> Essential: nothing
> Optional: bz2
However I find your actual positions confusing and each mails bring
opposing arguments about the shared work between other archives
extension and phar. Can you clarify your view please?
Essential: nothing
Optional: bz2, spl, zlib
Completely different and nothing whatever to do with phar: ext/zip
On Jan 28, 2008 9:38 PM, Gregory Beaver <[EMAIL PROTECTED]> wrote:
> Pierre Joye wrote:
> > Hi Greg,
> >
> > On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> >
> >>> Current status of phar addresses most of these criticisms:
> >>>
> >> Looks impressive, great work!
> >>
> >>
Pierre Joye wrote:
> Hi Greg,
>
> On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>
>>> Current status of phar addresses most of these criticisms:
>>>
>> Looks impressive, great work!
>>
>>
>>> phar implements zip support with native PHP code, enabling some fea
On Jan 28, 2008 8:56 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > I think it is a good thing to require ext/phar even for the read
> > operations. It certainly allows a shit load of optimization and tricks
> > that will never be possible otherwise. But Greg or Marcus will give us
> > a better answe
I think it is a good thing to require ext/phar even for the read
operations. It certainly allows a shit load of optimization and tricks
that will never be possible otherwise. But Greg or Marcus will give us
a better answer :)
? It's a < 7kb add-in stub to make it open-access.
- Steph
--
PHP In
Hi Steph,
On Jan 28, 2008 8:38 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> > Exactly and I'm rather surprised to see this post given the recent
> > efforts to export the Zip symbols to allow any extension to share the
> > zip features.
>
> I think until the zip features were shared the library's l
Hi Pierre,
Exactly and I'm rather surprised to see this post given the recent
efforts to export the Zip symbols to allow any extension to share the
zip features.
I think until the zip features were shared the library's limitations hadn't
been too obvious.
Most of the discussions have been
Hi Greg,
On Jan 28, 2008 7:52 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> > Current status of phar addresses most of these criticisms:
>
> Looks impressive, great work!
>
> > phar implements zip support with native PHP code, enabling some features
>
> I am a bit confused about native PHP c
Stanislav Malyshev wrote:
>> Current status of phar addresses most of these criticisms:
>
> Looks impressive, great work!
>
>> phar implements zip support with native PHP code, enabling some features
>
> I am a bit confused about native PHP code here - we are talking baout
> an extension, right? So
Current status of phar addresses most of these criticisms:
Looks impressive, great work!
phar implements zip support with native PHP code, enabling some features
I am a bit confused about native PHP code here - we are talking baout an
extension, right? So what exactly is meant here?
Also, a
Hi all,
I have been working hard on pecl/phar to address several issues raised
last May when it was first mentioned on the list, and would like to
summarize where phar stands today with regards to those criticisms:
Criticisms:
* non-standard file format
* limited introspection
* no support fo
19 matches
Mail list logo
