Newsgroups: php.apc.dev,php.internals
Path: news.php.net
Xref: news.php.net php.apc.dev:193 php.internals:43187
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain tekrat.com from 208.43.138.18 cause and error)
Message-ID: <49A6E6C8.90801@tekrat.com>
Date: Thu, 26 Feb 2009 11:00:24 -0800
User-Agent: Postbox 1.0b7 (Macintosh/2009020805)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
CC: Gopal V <gopalv@yahoo-inc.com>, 
 PHP Internals List <internals@lists.php.net>,
 apc-dev@lists.php.net
References: <49A097FE.10205@tekrat.com> <49A6A82C.9030504@yahoo-inc.com> <49A6C4D1.2060706@lerdorf.com>
In-Reply-To: <49A6C4D1.2060706@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
From: shire@tekrat.com (shire)

Rasmus Lerdorf wrote:
> Gopal V wrote:
>> shire wrote:
>>
>>> http://tekrat.com/downloads/bits/apc_lazy_php53.patch
>>>
>>> You should be able to apply the above patch to the latest PHP_5_3
>>> branch, and recompile the latest APC CVS against it.  Two ini settings
>>> enable/display lazy loading:
>>>
>>> apc.lazy_functions=On/Off
>>> apc.lazy_classes=On/OFf
>> Awesome!
>
> Yup, I am all for the lazy loading patch as well.  I don't think people
> really realize how much code they load that is never run.  Especially
> all the folks with massive front controllers.


Thanks, I would be interested in hearing how successful it is on different setups just to validate it.  I'll start making some more cleanups to the patches and more optimizations in the next month or two so hopefully we'll see some additional improvements in the code and performance.



>
>>> Alternative implementations would include replacing the function
>>> entries with an internal function that would load the opcodes when
>>> called, however I found this implementation to be problematic, still
>>> requires changes to PHP, and would also require inserting entries into
>>> the function/class tables which itself ends up being an expensive task
>>> for extremely large codebases.
>> I still haven't given up on the executor hooks. But can't argue with
>> code that works (yes, it works for most of my tests).


By executor hooks do you mean actually the executor hooks in Zend, or replacing a stub in the function table like I described?  I like the idea of stubbing out function table entries, but I think this makes it difficult to avoid the costs of updating the function table, I'm hoping that I can make some optimizations that cut this down so I guess we'll see in a while if I'm able to do that as it might shed some light on how much we can gain by going one way or the other etc.  If you're thinking of something else (I know we discussed this before, but maybe I misunderstood), I'd like to hear the details.  ;-)



>>
>> I should finish up the RO patches in place so that we can catch stuff
>> being overwritten in shm without locks - reflection, xdebug and suhosin
>> looks like potential culprits here.


I thought this was awesome when I read your blog post, should be great!



> I wouldn't worry about xdebug at all.  We should probably just turn off
> the opcode cache part when xdebug is active if it is a problem.

I agree for the general case, in our development environment though this might cause some pains.  But we could always start there and see how it goes.   I agree that Xdebug isn't really a use case we always need to optimize for.
  

-shire