Re: Function caching...

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 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, 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. Zeev -- Zeev Suraski <zeev@zend.com> CTO, Zend Technologies Ltd. http://www.zend.com/