Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43327 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97191 invoked from network); 11 Mar 2009 22:49:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Mar 2009 22:49:09 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 88.198.8.16 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 88.198.8.16 bigtime.backendmedia.com Linux 2.6 Received: from [88.198.8.16] ([88.198.8.16:49395] helo=bigtime.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E8/52-09289-4EF38B94 for ; Wed, 11 Mar 2009 17:49:09 -0500 Received: from localhost (unknown [127.0.0.1]) by bigtime.backendmedia.com (Postfix) with ESMTP id 464E71EBC013; Wed, 11 Mar 2009 22:50:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at backendmedia.com Received: from bigtime.backendmedia.com ([127.0.0.1]) by localhost (bigtime.backendmedia.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqF7mRRkZjKH; Wed, 11 Mar 2009 23:50:56 +0100 (CET) Received: from [192.168.0.151] (77-58-151-147.dclient.hispeed.ch [77.58.151.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mls@pooteeweet.org) by bigtime.backendmedia.com (Postfix) with ESMTP id 664C34144009; Wed, 11 Mar 2009 23:50:54 +0100 (CET) Cc: Rasmus Lerdorf , Dmitry Stogov , PHP Internals List , apc-dev@lists.php.net, Andi Gutmans , Stas Malyshev Message-ID: <6AF534FA-4724-49A9-8B3B-A9D30CB2A57C@pooteeweet.org> To: shire In-Reply-To: <49B817CB.5070403@tekrat.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 23:49:01 +0100 References: <49A097FE.10205@tekrat.com> <49B6AF73.2050506@tekrat.com> <49B75142.2090808@zend.com> <49B77363.4040000@tekrat.com> <49B7E092.2070004@zend.com> <49B7E291.3050807@lerdorf.com> <49B817CB.5070403@tekrat.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [PHP-DEV] Re: [APC-DEV] Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading From: mls@pooteeweet.org (Lukas Kahwe Smith) 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 mls@pooteeweet.org