Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33782 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30439 invoked by uid 1010); 5 Dec 2007 23:12:10 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 30424 invoked from network); 5 Dec 2007 23:12:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2007 23:12:10 -0000 Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.94.239.7 mail.jdi-ict.nl Linux 2.6 Received: from [82.94.239.7] ([82.94.239.7:43038] helo=mail.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C8/57-12052-74037574 for ; Wed, 05 Dec 2007 18:12:08 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id lB5NC4Y0031274; Thu, 6 Dec 2007 00:12:04 +0100 Date: Thu, 6 Dec 2007 00:12:06 +0100 (CET) X-X-Sender: derick@kossu.ez.no To: Matthias Pigulla cc: Andi Gutmans , PHP Developers Mailing List In-Reply-To: <00A2E2156BEE8446A81C8881AE117F199A0680@companyweb> Message-ID: References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> <00A2E2156BEE8446A81C8881AE117F199A067C@companyweb> <00A2E2156BEE8446A81C8881AE117F199A0680@companyweb> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Subject: Re: AW: AW: [PHP-DEV] Garbage collector patch From: derick@php.net (Derick Rethans) On Wed, 5 Dec 2007, Matthias Pigulla wrote: > > > Is it possible to always perform (unconditionally compile in) the > > > necessary housekeeping tasks but stick with the current GC, so that > > > cycle-detection only happens when the user calls a > > > gc_go_find_cycles() > > > function? Would that significantly improve the above numbers? > > > > Yes, that would be possible, but it wouldn't speed anything up in case > > you don't have any cycles. > > Not sure I got you right. That is, the speed penalty comes from > housekeeping? Does the new GC try to find cycles automatically > whenever a refcount goes down to zero? Not immediately... the algorithm should only run when either the root buffer is full, or the function is run manually. > If building and maintaining data structures for the algorithm costs > only a little memory but speed impact is neglegible unless the > algorithm actually runs, then you could stick with the > non-cycle-detecting "legacy" GC (= speed) unless you know you have > cycles and/or want to trade a little processing time (a call to > gc_go_find_cycles()) for the memory it will/might free. Yes, exactly. But it's just as easy to turn automatic cleaning as well - in that case the find cycle algorithm will kick in at some specific amount of "freed" vars. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org