On Apr 7, 2012, at 5:22 AM, Pierre Joye <pierre....@gmail.com> wrote:
> hi, > > 2012/4/7 Luke Scott <l...@cywh.com>: > >> It would be ideal of you could initialize a bunch of objects once and >> carry them over to the next request. No serialization, no copying. A >> lot of framework objects would benefit from this. > > The expensive parts here are not the object creation on its own but to > get the data they contain (external, calculation, etc.). With heavy objects, yes. But when you have hundreds of objects? The unseralization process in no more efficient than creating the objects directly. > That's why we have magic methods like __sleep and __wakeup. Making > objects or values persistent across requests is not possible or very > hard. It is way cleaner to create them on each request and save the > expensive computation or data fetching time (see doctrine for example) > instead of trying to figure out tricks to get rid of the references > and all other ways to mess up a zval between requests. It depends. It's only cheaper when you have heavy objects. How do other platforms with a persistent application instance handle this? I don't believe references are really that big of an issue. You still have scope and refcounts. The difference is now refcounts are ignored and everything is thrown away at the end of the request vs refcounts being observed and memory persisting past the request. I think the bigger issues are how to persist the memory without fragmentation. Stanislav talked about that (although those comments didn't make it to the list - my fault for not hitting reply all). > The serialization method can be optimized easily, igbinary for example > can help to speed up this process. Optimized, sure. But you can only go so far. You still have the cost of recreating those objects. The only way to make it truly zero is by not recreating them. igbinary helps. But what about a large binary tree? The only way to efficiently keep this in memory (currently) is to write a C/C++ extension that persists the memory as a resource. But this takes much more time and effort than writing it in PHP. > It is also important to keep in mind that PHP is not designed to have > persitant user land values and won't be. > There are very good tools to > store these data, like memcached, couchbase, redis and co for the > distributed ones, apc and other for local caches (even like mysqlnd_cc > for caching mysql results :). And these are great solutions to a different set of problems. But they aren't the token solution to every problem. With a lot of large frameworks you spend more time initializing the framework than the request itself (besides querying external resources like MySQL). I think the most frustrating thing for me is knowing this isn't an issue with web applications written in Java, which has an always on application instance that handles requests. I've always viewed java as bloated and slow... But with recent developments of Java being jit compiled to native code, these issues are starting to go away. I have invested 10 years into PHP. Id rather stick with what I know. But it scares me that many enterprises in our sector chose Java over PHP. Luke > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
