Newsgroups: php.apc.dev,php.internals
Path: news.php.net
Xref: news.php.net php.apc.dev:202 php.internals:43302
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <49B75142.2090808@zend.com>
Date: Wed, 11 Mar 2009 08:50:58 +0300
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: shire <shire@tekrat.com>
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
 PHP Internals List <internals@lists.php.net>,
 apc-dev@lists.php.net
References: <49A097FE.10205@tekrat.com> <CB8259C8-6F46-445D-B15C-D7BE33B72233@pooteeweet.org> <49B6AF73.2050506@tekrat.com>
In-Reply-To: <49B6AF73.2050506@tekrat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
From: dmitry@zend.com (Dmitry Stogov)

Hi,

Personally, I like the patch except for some small possible tweaks, and 
I believe it can't make any harm with lazy loading disabled.

Could you provide some benchmark results?
APC patch to play with it and see advantages/disadvantages?

Thanks. Dmitry.

shire wrote:
> Lukas Kahwe Smith wrote:
>>
>> On 22.02.2009, at 01:10, shire wrote:
>>
>>>
>>> I've just checked into APC CVS preliminary support for Lazy Loading
>>> classes and functions. This means that rather than copying function
>>> entries into EG(function_table) and EG(class_table) when an include
>>> happen it will mark the functions/classes as available and only
>>> actually insert them into the tables when they are called. This is
>>> done via hooks added into the various hash table lookups in PHP. I've
>>> placed a patch for PHP_5_3 at:
>>>
>>> http://tekrat.com/downloads/bits/apc_lazy_php53.patch
>>
>>
>> I did not read through the entire thread. As things are close to RC
>> state in 5.3, I would prefer to not do any non bug fixes at this stage.
>> Then again if the benefits are huge and the risk is low it can be
>> considered of course ..
> 
> 
> Yep, I should have been clearer here. ;-)   I don't believe this patch 
> is ready to be committed and I'm not advocating for inclusion in the 
> php53 release.  I have some more adjustments I'd like to make to both 
> the APC code and this patch, both for optimization, cleanliness, and to 
> ensure it's the best possible implementation for future enhancements 
> (such as lazy loading methods).  I'm more interested in getting 
> constructive feedback and any benchmark results so I can make 
> adjustments to the current code.  However, I would like to come back 
> with improved patches and get it included in the next major release as 
> appropriate.
> 
> I'm all about fixing the remaining php53 todos/bugs and getting this 
> release out!  I hope posting this wasn't a distraction from that.
> 
> Thanks!
> 
> -shire
>