Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:33756 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25635 invoked by uid 1010); 5 Dec 2007 18:45:04 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 25620 invoked from network); 5 Dec 2007 18:45:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Dec 2007 18:45:04 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; 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:37796] helo=mail.jdi-ict.nl) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2B/7D-20707-AA1F6574 for ; Wed, 05 Dec 2007 13:45:00 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.jdi-ict.nl (8.13.7/8.12.11) with ESMTP id lB5Iiov0022762; Wed, 5 Dec 2007 19:44:50 +0100 Date: Wed, 5 Dec 2007 19:44:52 +0100 (CET) X-X-Sender: derick@kossu.ez.no To: Matthias Pigulla cc: Andi Gutmans , internals@lists.php.net In-Reply-To: <00A2E2156BEE8446A81C8881AE117F199A067C@companyweb> Message-ID: References: <698DE66518E7CA45812BD18E807866CEF88FDD@us-ex1.zend.net> <00A2E2156BEE8446A81C8881AE117F199A067C@companyweb> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Subject: Re: AW: [PHP-DEV] Garbage collector patch From: derick@php.net (Derick Rethans) On Wed, 5 Dec 2007, Matthias Pigulla wrote: > > 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? > > 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. Derick