Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66475 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83689 invoked from network); 5 Mar 2013 18:59:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Mar 2013 18:59:52 -0000 Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:57922] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/14-58003-7A046315 for ; Tue, 05 Mar 2013 13:59:52 -0500 Received: from [192.168.2.20] (ppp-188-174-59-130.dynamic.mnet-online.de [188.174.59.130]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id CAD8E65A96; Tue, 5 Mar 2013 19:59:47 +0100 (CET) To: nathan@starin.biz Cc: internals@lists.php.net In-Reply-To: <0f1001ce19ce$8ce5a260$a6b0e720$@starin.biz> References: <0f1001ce19ce$8ce5a260$a6b0e720$@starin.biz> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Mar 2013 20:00:48 +0100 Message-ID: <1362510048.2382.570.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Memory warning hook From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Tue, 2013-03-05 at 12:23 -0600, nathan@starin.biz wrote: > As PHP applications are turning into large frameworks one of the issues > arriving is memory management. One of the issues is that many frameworks use > sophisticated caching techniques to make accessing the same data quickly, > this improves speed it is at the cost of memory. Often the developer knows > these areas that cache and often times already have functions in place to > clear out the cache, however in the case where PHP is approaching or exceeds > memory limits PHP runs the GC then dies if it cannot allocate enough memory. > If we implemented "memory warning" triggers or user function that will be > called before the GC is executed which allows the user to try and free up > some memory on their own. This hopefully would give more flexibility to > allowing these advanced caching techniques but at the same time allow the > cache to be cleared out in case memory is getting low. Running the GC is most likely faster than most cleanup routines a user could run, also usually there is not that much stuff cached in PHP scripts. If a PHP script has "tons" of data, which it can easily throw away, in memory this sounds like a smell of an bad architecture. Cache cache-worthy stuff in memcache or such and fetch only the data you need. Also: What should happen if the system runs out of memory while doing the cleanup? Anything sane doesn't sound good either. johannes