Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19462 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68350 invoked by uid 1010); 7 Oct 2005 06:50:13 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 68334 invoked from network); 7 Oct 2005 06:50:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Oct 2005 06:50:13 -0000 X-Host-Fingerprint: 195.225.34.5 fw01.axit.nl Received: from ([195.225.34.5:10324] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 30/DD-54476-4AA16434 for ; Fri, 07 Oct 2005 02:50:12 -0400 Message-ID: <30.DD.54476.4AA16434@pb1.pair.com> To: internals@lists.php.net References: <4E0C5C8E5F8C994F90134920DD66E93F01129374@pearl.hq.booyahnetworks.com> Date: Fri, 7 Oct 2005 08:45:24 +0200 Lines: 54 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Posted-By: 195.225.34.5 Subject: Re: [PHP-DEV] Re: CLI in PHP6 From: r.korving@xit.nl ("Ron Korving") That would be nice. If all memory, even the stuff allocated by functions, is freed at the end of the request, I can see where the problem is. It would be very useful if this memory really would be freed at the moment all references to it disappear. This would be a lot better for the CLI environment, but also for a web environment, if you ask me, because the memory required for handling pages might just be reduced by a big percentage. I guess the question is: would this be a big performance hit in processing time? (and I fear the answer is too big a "yes", otherwise I expect it would've already been implemented). Ron "Jani Taskinen" schreef in bericht news:Pine.LNX.4.61.0510062142470.27450@arfg.argcubovn.sv... > > There was some mail about the memory handling some time ago on > this list..something about making it better in these cases.. > Try search the archives for this. (I can't find it right now) > > IIRC, there even was a patch.. > > --Jani > > On Thu, 6 Oct 2005, J. Allen Dove wrote: > > > Unset() != free() is the bummer in the CLI env. :-( Def could use that > > to help shape the performance contour in a daemon env since the > > "request" never ends unless you self-terminate. Even then it can be > > tricky to get that lifetime right if your loads change, etc. > > > > -- AD > > > >> "leak", which honestly surprised me. We even explicitly unset the vars > >> but that doesn't guarantee the GC kicks off for them near-time? > >> > >> unset() != free(). The memory allocated is still freed during > >> the request shutdown (where GC actually kicks in). > >> > >> As a total aside, and being a paranoid C++ guy, I would love a "free" > >> method that I could call that frees what I tell it to exactly when I > >> tell it to... :-) > >> > >> I think someone requested this before but it was shut down for > >> some reason..can't remember what it was again. > > > > > > -- > Give me your money at @ > Donating money may make me happier and friendlier for a limited period! > Death to all 4 letter abbreviations starting with P!