-- David Muir <[email protected]> wrote (on Thursday, 26 August 2010, 01:33 AM -0700): > > I'd be more interested in a way to "bake" the application. > Paddy had a post about ZF vs Symfony performance. > http://blog.astrumfutura.com/archives/421-PHP-Framework-Benchmarks-Entertaining-But-Ultimately-Useless.html > In it he builds some optimised builds that skips Zend_Application and has a > bunch of classes combined into a single file. It would make a lot more sense > to have a zf tool to automate something like that than to cram the > application into the session.
Well, the improvements we're working on may obviate the need for such "baking" -- we're seeing tremendous potential performance gains with refactored autoloading and plugin loading, which are the real bottlenecks of Zend_Application. If those bottlenecks go away, we may not see a significant improvement from doing something like Paddy suggests. That said, we are seeing some places where we can create deployment-time optimizations (generation of autoload classmaps, etc.), and we'll likely build some tools around those processes. But first, let's see if we can make significant strides with these other, fundamental areas. > The session is there for user state and temporary data persistence, > not err.. logic persistence? Exactly -- the session is to hold the few items necessary to make the application stateful, no more. Typically, in PHP, this means items related to a specific user or browser session -- user data, cart data, etc. Data. The logic is persisted in the code itself, and gains no significant benefit from session persistence -- as Ralph notes, you still need to unserialize the code, which often involves loading dependencies, etc. Application caching should be done at the opcode cache level -- and those solutions are drop-in. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
