Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:6849 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89526 invoked by uid 1010); 8 Jan 2004 13:24:36 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 89492 invoked from network); 8 Jan 2004 13:24:36 -0000 Received: from unknown (HELO xaxa.search.ch) (195.141.85.118) by pb1.pair.com with SMTP; 8 Jan 2004 13:24:36 -0000 Received: from localhost (localhost [127.0.0.1]) by xaxa.search.ch (Postfix) with ESMTP id 5BF596DB02; Thu, 8 Jan 2004 14:24:35 +0100 (CET) Received: by xaxa.search.ch (Postfix, from userid 65534) id 5AB8B6DB25; Thu, 8 Jan 2004 14:24:34 +0100 (CET) Received: from cschneid.com (ultrafilter2-i [192.168.85.3]) by xaxa.search.ch (Postfix) with ESMTP id BBEAF6DB02; Thu, 8 Jan 2004 14:24:33 +0100 (CET) Message-ID: <3FFD5A11.3040500@cschneid.com> Date: Thu, 08 Jan 2004 14:24:33 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031009 X-Accept-Language: de-ch, en-us, en MIME-Version: 1.0 To: Stanislav Malyshev Cc: Andi Gutmans , internals@lists.php.net References: <5.1.0.14.2.20040108100152.02029de8@127.0.0.1> In-Reply-To: X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on xaxa.search.ch X-Spam-Level: X-Spam-Status: No, hits=-0.9 required=5.0 tests=BAYES_10 autolearn=ham version=2.61 X-Virus-Scanned: by AMaViS 0.3.12pre8 Subject: Re: [PHP-DEV] Ability to lower PHP memory usage From: cschneid@cschneid.com (Christian Schneider) Stanislav Malyshev wrote: > I'm concerned that this problem of breaking common platform might be more > dangerous than the performance benefit. Which, BTW, I estmate as pretty > minimal - code space is shared on all modern OSes anyway, so a little I think that's a good point for leaving it the way it is: Minimal benefit while opening a can of worms of possible problems. Another reason not to do it is the amount of work to decide which function should go where. Let's keep it simple and focus on IMHO more pressing problems. - Chris