|
|
Posted by Xuefer Tinys on 01/08/05 20:36
even apc/eAcc have to copy from shm to php-memory(alloc by emalloc),
because $array might be modified anytime
i'd guess this is almost same as serialize/unserialize
i doubt if there's anyway to have 1 memcpy $array<-from/to->shm, php
will release 1 element of $array when the element is unset(refcount=0)
maybe apc set element refcount+1, so it won't free by php, but apc
free the whole block itself? or rely on zend memory manager to free?
apc opcode seems doing this way, but i don't know it much.
sth off topic:
the constant-array definition imho, should be optimized to which like
static variable but each time get a new copy
$a = array(...big..)
to:
static $__a = array(....big...)
$a = $__a;
it seems static var isn't store as opcode, i'm not quite sure
well, end of off topic :)
On Thu, 06 Jan 2005 10:58:07 -0800, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> Adrian Madrid wrote:
> > I think I understand where you're coming from. I've had a similar
> > problem and the best solution I've found is eAccelerator (previously
> > known as Turck MMCache). What EA does is keep the bytecodes PHP compiles
> > inshared memory so next time you need that script PHP doesn't need to
> > recompile, EA returns the bytecode from SHM. Now, since PHP scripts are
> > compiled and saved in SHM all I need to do is /save/ the data that does
> > not change often but requires a lot of queries as code (an array inside
> > a script) and include it whenever I need the data. No recompiling, no
> > need to touch the DB again, pure speed. I hope all this helps you. I
> > personally don't need extra processes and stuff like that but if you
> > really want all that you can take a look at phpbeans.
>
> What you are talking about is opcode caching. While it certainly speeds
> things up, it can be done much faster. When you cache a file that
> contains a large PHP array definition, all you are caching are the
> instructions to create that array. On every request these instructions
> need to be loaded from shared memory and executed in order to recreate
> the array. This can be quite slow. What we are discussing here are
> ways to avoid recreating the array on every request which is quite
> different.
>
> -Rasmus
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Navigation:
[Reply to this message]
|