Re: Function caching...

Zeev Suraski wrote: > At 17:54 11/12/2000, Andrei Zmievski wrote: > > You misunderstood what my message was referring > >to: it was about having a central index.php file that handles all the > >requests instead of having separate .php files for different pages. > Well, I don't remember this entire heated conversation by heart, and it was > hardly clear from those two sentences, taken out of context, what you meant... >Snip_> > Mind you, *because* PHP doesn't perform very well with the approach he's > taking, he wants to change it upside down so that it does. That's where we > should tell him to stop, and rethink *his* design, instead of saying 'Sure, > why not, lets redesign PHP'. A refresher of the PHP "raping".... :) Ulf Wendel wrote: > Jacob Verhoeks wrote: > > I'm developing a large web application. > > The code is very large now (2mb). > > The performance problem is not with executing but with the loading of the > > code. We are currently developing a application server in php. That will be > Yes the compile (loading) time is much to long. PHP 4 need ~1 second to > compule 8k loc on out developement server (Netra T1). The Zend Encoder > and Zend Cache might improve this dramatically. Jacob Verhoeks also wrote: > we don't have pages, we use a rewrite rule to redirect everything to one > index.php which then loads and parses a template based on the uri. There's a few more cases that have been brought up in this discussion.... While "raping" is quite a colorful term, many the general problems which are inspiring a "cache" are centered around repeatedly calling the *same functions*, the *same code*, from singular pages, or small page sets... regardless of whether or not that code is needed for the dynamic portions of the content. (Just imagine loading PHPlib, and Fastemplates, and Metabase, and some mail classes, some tables classes, etc. for each and every page load) The actual issues, as I see them, are as follows: 1. Function/result caching. Nobody's really suggested a reason why this _shouldn't_ happen, only posted issues about why we don't want to alter significant internal architecture portions to accomplish it. I like the idea, even though it has limited utility to me (I code my PHP differently). Implementation issues... well, see #3. 2. Optimizing PHP code. Re-loading 8000 of the *same* lines, every page, is something that PHP does very poorly. Unfortunately, nobody's really pointing out why coding PHP this way is a Bad Thing (tm), so I wouldn't be surprised if there are quite a few people suffering for these same problems. Perhaps we need more words/articles/doc chapters/whatever spread to the community on various ways of writing code *with PHP's abilities and limitations in mind*. Of course, a frequent complaint in any language is "XYZ does it better, why can't PHP", so there are people who will want it to be more OO, others will want a GOTO, others want an app server, etc.. etc.. 3. Other speed/process issues... these are about resource pooling, global (to PHP, not a PHP process) variables/session data, etc. Many probably cannot be done efficiently within Apache/PHP, and may need a side application. We have lots of side applications we already pass data to and from, so this could be written by somebody willing to take on a *much* larger project or a set of side projects... a) "Session tracking app", basically a shared memory storage, which had a uniform set of functions that tied into PHP via session functions. b) "DB Multiplexor app" a db connection application, that aggregated db calls. c) "Page cache app" Another storage app, basically a memory area where users could pull pre-cached results from. etc. etc. But hey, it's open source. If somebody wants the code bad enough, they can write it, rather than expecting the PHP core developers to do it for them. They can nicely solicit help, rather than accusing PHP of being "8/15" and insulting the developers or current code base. They can offer to pay for it. They can submit feature requests. They can fork off. -Bop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not neccesarrily those of myself, my employers, or any of the other little voices in my head.