On Apr 7, 2012, at 9:45 AM, Pierre Joye <pierre....@gmail.com> wrote:
> hi, > > On Sat, Apr 7, 2012 at 4:59 PM, Luke Scott <l...@cywh.com> wrote: > >>> 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 what I am saying, yes. Hence that I do not think persistent > objects are that much helpful. I guess it depends on the use case. > >> It depends. It's only cheaper when you have heavy objects. >> >> How do other platforms with a persistent application instance handle this? > > It is horrible in Java. There are some work being made in JS (server > side) too which looks good, but it is basically the same as we discuss > here. Are we talking about v8cgi or Node? Node has a single application instance, but everything has to be asynchronous... > >> 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). > > Then post it again here. Done. > >>> 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. > > Right, but the gain is not worth it except in hello world example. > Well, for the large majority of the use cases. In a hello world the difference is probably not measurable. When you start to see it is with hundreds of class instances. > >> 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. > > I wonder about the opportunity and design correctness to keep large > binary trees in memory, but that's maybe another discussion :) I personally don't, but it was one of the use cases I found where serialization had no benefit. > > >> With a lot of large frameworks you spend more time initializing the >> framework than the request itself (besides querying external resources >> like MySQL). > > In most if not any applications, "(besides querying external resources > like MySQL)" is what takes the largest part of the request time. > That's why I do not think persistent zval is going to bring us that > far. True, for most PHP applications today. But when you hit these limitations you often have to work outside PHP and bind that solution to it. Whereas java, as "horrible" as it is, can handle almost any situation. A classic example of something I couldn't do in PHP: Large file uploads (> 2GB). Our solution was writing an app in java, powered by jetty, to stream the file to the server. It works beautifully , but it had to be done outside PHP. > > >> 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. > > It is not really what I see. Many projects I have seen have been > moving away from persistent objects across requests (for the part you > are referring to here), as it adds an insane amount of complexity that > is not worth the effort. I suppose it depends on the industry. In the credit card processing industry (gateways) I see Java a lot. I almost never see PHP in this area. 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
