Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33737 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73852 invoked by uid 1010); 5 Dec 2007 16:47:40 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 73837 invoked from network); 5 Dec 2007 16:47:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2007 16:47:39 -0000 Authentication-Results: pb1.pair.com smtp.mail=mp@webfactory.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mp@webfactory.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain webfactory.de from 195.227.108.51 cause and error) X-PHP-List-Original-Sender: mp@webfactory.de X-Host-Fingerprint: 195.227.108.51 wfserver02.wf-ppr.de Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [195.227.108.51] ([195.227.108.51:22238] helo=wfserver02.wf-ppr.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BD/25-20707-B26D6574 for ; Wed, 05 Dec 2007 11:47:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Dec 2007 17:47:36 +0100 Message-ID: <00A2E2156BEE8446A81C8881AE117F199A067C@companyweb> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PHP-DEV] Garbage collector patch Thread-Index: AcgodbBUeVD1ojsgR3+ExaIaGvi/7gHdK76wAYEbqmAAW5Xb4A== References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> To: "Andi Gutmans" , Subject: AW: [PHP-DEV] Garbage collector patch From: mp@webfactory.de ("Matthias Pigulla") > To summarize the patch lead to approx. 5% slowdown and 3% memory > overhead for typical applications (as always, you mileage may vary > depending on your system's architecture and OS although my guesstimate > is that you will see even worse results in a 64bit environment). Does that slowdown result from housekeeping tasks alone that are a prerequisite for GCing or does it include running the new algorithm?=20 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? -mp.=20