Stig,
Actually, I've crawled through the Zend source, taken a look at all the startup/shutdown routines, mapped everything out and it doesn't too bad at all. I've started writing code and so far so good. If everything goes well I should be announcing a solution sometime in January. I had considered modifying Zend to add a global scope directly to the language but because of the way they have things set up I'd have to modify all the modules as well ... too much work right now. This is a classic example of why using global externals is a very bad idea and Zend uses them all over the place. I agree that running a remote server to handle persistence is a much easier way to go but it's not really something I want to do. If I can't get this to work I'll give that a try. -- Yermo On Wed, 5 Dec 2001, Stig S. Bakken wrote: > Importing objects into the current Zend/PHP instance and then updating > them at request shutdown introduces a lot of tricky synchronization > problems, I think it's very difficult to implement reliably with Zend as > well. > > IMHO a better solution would be using a remote object access mechanism. > There are several choices available today, such as Corba, SOAP or > XML-RPC (check out php4/pear/PEAR/Remote.php for an example > implementation using XML-RPC). According to Derick, SRM can do this > today, which would probably be a lot faster than both Corba and the > XML-based protocols. > > - Stig > > "Yermo M. Lamers" wrote: > > > > I took a look at Zend Accelerator/Cache. That's not really what I'm > > looking for. > > > > It's basically just a pseudo-compiler that caches compiled versions of > > pages. It's not really a "live object cache". > > > > What I'm looking to do is to create a global scope where I can keep live > > pre-built instances of objects around. I agree the accelerator would > > improve the performance, but in my case it wouldn't improve it enough. > > > > I think I can probably get an order of magnitude performance improvement > > by pre-caching live objects and making them available to all pages in an > > application ... very much like mod_perl does. > > > > With the pseudo-compiler you get an improvement, but you're still building > > all your objects on every page, using them and destroying them .. you're > > just avoiding the load/compilation step. I want to avoid the > > load/compilation and instantiation steps because in my case, and for any > > really involved system, insantiation is going to be expensive. > > > > It looks like it should be doable if I can copy symbol tables in and out > > of the zend interpreter, but it's not clear to me what portions get tied > > inextricably to a given zend interpreter instance. > > > > -- Yermo > > > > On Mon, 26 Nov 2001, Andrei Zmievski wrote: > > > > > On Mon, 26 Nov 2001, Andrei Zmievski wrote: > > > > Yeah, it's already built and it's called Zend Encoder. > > > > > > Sorry, Zend Cache or Zend Accelerator, not sure what the current name > > > is. > > > > > > -Andrei > > > > > > > > > "Freedom comes when you learn to let go. > > > Creation comes when you learn to say no." > > > -madonna > > > > > > > --------------------------------------------------------------------- > > DTLink Software [EMAIL PROTECTED] > > Software Development and Consulting > > --------------------------------------------------------------------- > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > To contact the list administrators, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- DTLink Software [EMAIL PROTECTED] Software Development and Consulting --------------------------------------------------------------------- -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
