[phpa] Re: my phpa thoughts...
- From: "Nick Lindridge" <nick@xxxxxxxxxxxxxxxxxxxxx>
- To: phpa@xxxxxxxxxxxxx
- Date: Wed, 30 Jan 2002 13:36:11 -0000 (GMT)
> Nick, have you thought about putting something like a paypal donation
> box to the phpa website? I would definitely contribute to the cause and
> I'm sure others would as well. Give us a way to buy you dinner once in
> a while or pay for your vacation to NY or something.! =)
Thanks for the comment and thought. Other's have suggested this too, and so
I've thought about it, but there are higher priorities than this so just
haven't had the time to look into that. I have a paypal account already so
it's probably simple.
> For a further performance boost with any version of phpa I would
> recommend sitting up a ram disk for the phpa cache (I have a 256MB ram
> disk setup for my /tmp directory which is were all my php code + html +
> phpa cache + etc files are stored. With the price of ram now-a-days
> this is a sure way (roughly $30) of trimming further microseconds off
> those php/html requests. Don't have any performance number to
> illustrate but I'm sure this would help.
I wouldn't necessarily put the phpa_ cache files there unless you have
plenty of space because they're generally only read once after being
created and access is then from shm. The memory could be used better
elsewhere.
> From reading the docs, phpa's "tweak" option optimizes the compiled
> code
> by reducing the number of run-tme memory allocation and other i/o
> stuff. How does phpa compares with ZendAccelerator (cache +
> optimizer)? Do you believe there is more potential headway in the
> caching part of phpa or the "optimization" part? Is it feasible with
> the source code out there to have phpa work with Zend Optimizer or is
> ZO too proprietary to make a glue module out of? Just my curiosity
> asking.....
The phpa optimiser does a number of simple optimisations. It modifies the
compiled code by changing post inc/dec to pre inc/dec when it can,
reorganises some code constructs to be more efficient, eliminates
unnecessary jumps to jumps or jumps to returns, removes some unreachable or
code that has no effect, coalesces string concats together (source code
like "This generates poor bad code $x" produces a number of string concat
instructions because of the way the string gets tokenised), and that's
about it. This maybe gets a few percent increase at most on execution.
It's measurable but only just.
The more effective optmisations eliminate variable lookups and other
operations that are in themselves quite expensive. Quite a while ago now I
had working optimisations that do this and the speed up was very evident,
but they were still experimental and didn't make it into the current
production optimiser. I may revisit this work later.
ZO does a number of things, including installing a new code execution
routine, that prevent it from easily working with other extensions. It
would be nice if it could coexist with phpa or apc, but it's not the end of
the world that it doesn't, particularly if the phpa optimiser gets beefed
up.
Once the zend engine rewrite starts to become available then that might
entail a rewrite of phpa, and so that may be where effort gets spent.
Nick
------------------------------------------------------------------------
www.php-accelerator.co.uk Home of the free PHP Accelerator
To post, send email to phpa@xxxxxxxxxxxxx
To unsubscribe, email phpa-request@xxxxxxxxxxxxx with subject unsubscribe
Other related posts:
