Re: Function caching...

Zeev Suraski wrote: > > At 14:34 12/12/2000, Ulf Wendel wrote: > > > 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. > > Persistent objects (for which you would use sessions today) is one > thing. Caching the return values of functions is another, much more > dangerous thing, and as I said, it comes with a price. dangerous features: Looking at http://www.phpbuilder.com/columns/peter20001107.php3 shows me people do not even understand the usage of OO. Wouldn't it be better to throw all the OO stuff away as people do not know how to use it? Using OO in a wrong way, they could slow down their applications and make them complicated.... dangerouse features: What's so dangerous about on a simple AppServer - the new global Hash $SESSIONS that can be used to make data persistant... function caching: I wasn't referring to it in my replay, I was talking about how nice web forms would be implemented in an application server enviroment. Event like design, persistent objects, persistent resources - wow! As far as the function caching feature goes, I'm nearly 100% satisfied with the userland implementeatio Sebastian Bergmann recently checked in to PEAR repository. If I get some delegate mechanism on top of it, it's nearly perfect. > >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. > > I disagree, especially as we're not talking about scaling. As a matter of > fact, you disagree as well, you just didn't notice it. Sorry, I can't get that point. I statet that scaling by hardware is limited as you told me to use more CPU power. Middle-sized web applications can't afford a dedicated machine. And there's an upper limit where you can't get more powerful machines. > You write your applications in PHP and SQL. Undoubtfully, if you wrote > your applications in Assembley or in C, using specialized databases, you > could end up with much more efficient results, orders of magnitude > faster. But since you haven't gone crazy, you don't do this, and instead, Let me cite from an E-Mail on the german php maling list. Obviously there already crazy guys that need to be cured: # Wirklich grosse Projekte mit sehr hohem Aufkommen, werden nach dem # Design in PHP oft in C gegossen um wirklich performant zu werden. # Das erlebe ich gerade selbst mit... # # # m.f.G. N. Pfeiffer # _____________________________________ # www.uris.de pfeiffer@uris.de # 0177-2363368 02292-681769 # ------------------------------------- (translation: real big project with lots of traffic often get designed in PHP and then translated into C to become fast. I'm currently dealing with such a project.) In later on Norbert told what he was referring to http://www.OnVista.de (>60.000.000 pageviews). > pick a scripting language which cuts your development time considerably, > and use a standard SQL database, which makes data storage much easier and > easier to develop. Both of those also significantly reduce the chances of > there being a bug in your code, since lots of the dirty work is being done > by the scripting language and the database. > Now, this comes at a price. You're paying this price on a minutely basis > every day, because your existing hardware can only serve X requests per > second due to your usage of PHP and SQL, instead of 5X or 10X requests per > second, if you were using Assembley and a specialized data storage. > > No doubt, your method will save execution time. But like any other methods > of cutting down on execution time (like the ones mentioned above), it comes > in a price. It may reduce the ease of use, it may make your application > less stable and more prone to bugs, and it may harm it otherwise. > > It's the most basic rule of computer science - it's one big world of tradeoffs. Tell this too all the brain death enterprise guys that translate PHP into C. Anyway, this is not my point. I was mainly talking about new ways to design todays web applications which requires an AppServer. With an application server we beware the ease of use of PHP, win the possibility to use new designs (web forms, table proxy => rapid application development) and become faster as we loose the session overhead. Ulf