Re: Function caching...

Zeev Suraski wrote: > > At 13:04 12/12/2000, Ulf Wendel wrote: > >If we had an AppServer that offers the features Kritian requested the > >time "lost" in my bad-nobody-needs-that abstraction would go down from > >now roughly 1.4s to less than 0.15s . I don't care a shit on this > >remaining 0.15s. But I do care on the compiling/loading time and I do > >worry the time the session stuff needs to rebuild my complex > >datastructures from scratch on every request. By help of a (still no > >avaiable but long time promised) Zend Cache I can avoid the 1.2s of > >compilation time but I still loose lots of time ~0.05s of the 0.20s > >(25%!) to rebuild my datastructures. > > Note that this comes at a price. It comes at a price of relying on the > static nature of your data structures, something which is usually not Maybe there's a misunderstanding here. If my objects were persistant within requests I would not need to rebuild them and fill them with session and HTTP request data over and over again. Once I have initialized my data structures using XML they dynamically change between requests. > true. As a general rule, the accepted behavior today is to pay that price, > because data consistency is more important than performance (again, you can > throw more or stronger CPUs on your server, but it's much more difficult o > hire more developers or worse, figure out how to recover from data > corruption). Of course, as all general rules, there are exceptions, Scaling by hardware is a very bad thing. It's not possible to use for every middle-sized web application a dedicated machine. If that's the future we have to switch from PHP to other solution which is not what we want as we love PHP. > perhaps many exceptions. It doesn't change the fact that the motivation > *does* exist to avoid caching things that cannot reliably be cached, or > that would force you to work in a very strict and prone-to-errors paradigm. > What the Zend Cache, as well as other components with a similar approach > towards performance improvement, is allowing you to keep the current, > reliable (stateless) development paradigm, and significantly reduce the > performance price that you have to pay for it. You see it from a different > point of view, and you want things to be as stateful as possible, to avoid > doing *anything* more than once, which is absolutely fine, and may very > well work for you as well as others. I'd argue that for most people, this > will probably not be the paradigm of choice for the Web environment. The Zend Cache is not available, free alternatives are. The Zend Encoder is also not available. It's true that many people ask for this products and will be satisfied. As I said I expect that the combination of Zend Cache and Zend Encoder will indeed boost my applications dramatically. Nobody doubts that. But that's not my point. If you want to stay in the market with PHP/Zend you have to provide enterprise solutions. Even if it's a small market that needs a super-duper AppServer it's the guys that can pay you and make your company successful. Professional web application development requires on the long run AppServer functionality to allow rapid prototyping which reduces development costs. The reduction of development costs is and was a strong argument for the usage of PHP. With help of the web form example I demonstrated one possible way to design tomorrows applications. It's a simple example and everybody here should be able to get the impacts of beeing able to rethink their designs. New designs could take PHP into a new dimension, into a new market (<blink>*money*</blink>). None of the beginners (our next employees) must use an AppServer and nobody must use sophisticated abstractions, but I and many others want to be able to step into a new decade of web application design. I named you some of them. The request based way is not what we need. We can work around the problems and limitations a request based architecture gives us. But it takes more and more time to do so. All these workarounds eat up the benefits of PHP. Ulf /me I'm looking on #irc php.de while I'm typing these lines. The hpttp://www.inbuit.de chief oracle programmer said: I'm going to switch to a another programming language. Someone aswered: Kosch, are you're mad! Reply: Sorry, looks as if PHP does not give me what I need.