Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading

[email protected] (Lukas Kahwe Smith) Wed, 11 Mar 2009 23:49:01 +0100
Newsgroups php.internals,php.apc.dev
Message-ID <[email protected]>
On 11.03.2009, at 20:58, shire wrote:

> Lukas Kahwe Smith wrote:
>> Can we get this patch to release quality by this weekend?
>> So that people can test it on Monday/Tuesday ahead of RC1?
>
> I don't see this being a problem, I do have a few items I'd like to  
> point out for feedback/suggestions:
>
> 1) Currently it doesn't support method level lazy loading, it's  
> probably advisable to wait and include this later, but if everyone  
> thinks it's significant enough we could probably add support for  
> that.  I'm not sure on all the details this involves, perhaps  
> someone familiar with method calls could suggest difficulty and/or  
> optimized ways to do the lookups.
>
> 2) Currently I've inserted these hook calls into everywhere we call/ 
> lookup classes.  This has the downside that any extension wanting to  
> mess with the function table, lookup entries, etc will need to be  
> aware of the callback hooks.  I think a better architecture is to  
> create an API for function table and class table operations.   
> Perhaps this could be done later if we want this likely more stable  
> version in 5.3, and perhaps I'm overstating the significance of  
> other functions doing these sort of things and not being aware of  
> this new feature.  (I believe dmitry mentions several extenions that  
> need changes to support this).  On the upside not creating an API  
> means existing code will still work if they don't use lazy  
> loading. ;-)
>
> 3) The largest portion of time currently is simply adding dummy  
> entries to the lazy hash tables so we can detect name collisions and  
> availability, my next goal is to improve the performance of this by  
> either creating a faster copy of the entries or determine some  
> better method of performing lookups/marking functions as available  
> (something like lookups directly into the APC shared memory  
> segment).  Just putting this out there in case anyone has some  
> interesting suggestions.
>
>
> I think all the above 3 items don't necessarily need to be done to  
> have this work in 5.3 (and #3 is pretty much APC/opcode cache  
> centric) and might cause unecessary complication for an initial  
> support of this, but what does everyone else think?


Hmm, thanks for your open assessment here. What you are saying does  
make me wonder if we really should push this into 5.3. Even if any  
changes we need to do can eventually be handled by APC, I do think  
that there will be other extension authors that would also suffer from  
us messing around with these internals all too much in every release.  
So maybe we should wait until the next bigger step before introducing  
this. Other people can apply the patch themselves if they really need  
the performance in the mean time ..

regards,
Lukas Kahwe Smith
[email protected]