Hi Michael,

Thanks a lot for your email! I must confess to, for once, not checking the 
web first and looking other products. I hadn't come across any others and 
was just aware of the Zend offering, hence putting together the accelerator. 
Now things are suddenly more interesting :-)

I would be suprised if the accelerator didn't come bottom of the performance 
tables at the moment compared to the others to be honest. Seeing as I hadn't 
looked at a line of php-4.0.6/Zend code before last Monday, the first 
milestone was merely to get something that worked at all :-) 6 days later I 
reached the first version that ironed out all showstoppers that I'm aware 
of. Intellectual exercise? Of course, what else, but the reason was that I 
needed a cache. Had I looked at the others then... well I'd have probably 
still started anyway having seen Zend outstripping the others <g>

Looking at the performance stats from John Lim back in January, it seems 
likely that all non-Zend caches are missing a fundamental trick or two. What 
do you think? For example, and this may be poor one because apc,bw,bez might 
all be doing this in one way or another, but when restoring a compiled file 
it can be that only a fraction of the functions/methods, and even entire 
classes are ever used. Loading the never used functions and classes and 
restoring unused static vars initialisers would quite literally be a waste 
of time.

Another thing that comes to mind is that you probably want to ensure that 
the usual cleaning up of memory that Zend does actually *doesn't* happen 
quite as completely as it does by default. I actually ask myself - do I want 
to restore compiled code from shared memory? Do I event want to restore 
compiled code from web server memory? And the answer is ideally no to both. 
And of course I don't want to restore from files. Bottom line, I actually 
don't want to *restore anything* if it requires any memory copying. Ideally 
I'd like the same hashtables, same function pointers, same static_variables, 
etc. etc. that were used last time a page was loaded. Not *copies of* these 

My ultimate goal, if I were making this a full time project, would be to 
'get' all the state I needed by a single lookup for the value of 
compiler/executor_globals using the i-number for the root source file in a 
devno specific structure. No copying of anything. Of course this might be 
unrealistic, but I'd want to know why, and focus not just how can I speed 
things up, but how can I eliminate what is slowing me down!

Another part of the engine that seems 'fair game' is the executor. One might 
perhaps reduce the size of CG(class_table) and CG(function_table) for 
example by switching between tables that contain just the likely or 
reachable items from certain points in the code. It's also possible to 
hijack what would normally be fatal errors, regard them as faults rather 
like a page fault, patch up what caused the error on the fly, such as a 
function lookup failure, and carry on as though nothing happened. Again, 
perhaps other cache developers are getting mileage from this, or perhaps 
there is no mileage in this, or perhaps there is and they are not?

And then there's a zend_op->C->nativecode.so optimiser that produces .so 
files of your scripts when there's nothing else better to be getting on with 


>From: Michael Kimsal <[EMAIL PROTECTED]>
>To: PHP Accelerator <[EMAIL PROTECTED]>
>Subject: Re: [PHP] Free PHP runtime Accelerator for Linux available
>Date: Tue, 21 Aug 2001 09:27:53 -0400
>Hello Nick,
>First off, thanks for your contribution.  We've not tested it as of yet,
>but it's
>always good to see more people getting involved at some level.  :)
>Second, have you compared the mechanism(s) you use against APC or bware?
>Have you considered perhaps helping with one of those projects instead of
>starting from scratch?  It sounds like this was primarily an
>intellectual exercise for you
>to begin with, so I can understand the DIY mindset.  However, if you've
>got many ideas
>for improving things further (PHP code optimization, reduced CPU time,
>etc) perhaps
>helping out with a more established project would benefit everyone more
>in the long run.
>Just some thoughts.  :)
>Thanks again
>Michael Kimsal
>PHP Training Courses
>PHP General 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]

Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

PHP General 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]

Reply via email to