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
things.
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
:-)
Nick
>From: Michael Kimsal <[EMAIL PROTECTED]>
>To: PHP Accelerator <[EMAIL PROTECTED]>
>CC: [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
>http://www.tapinternet.com/php/
>PHP Training Courses
>734-480-9961
>
>
>
>--
>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]
