Re: re-proposal of pecl/phar for inclusion in core

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