Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:24996 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48176 invoked by uid 1010); 27 Jul 2006 11:19:52 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 48160 invoked from network); 27 Jul 2006 11:19:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jul 2006 11:19:52 -0000 X-PHP-List-Original-Sender: edink@emini.dk X-Host-Fingerprint: 192.38.9.232 gw2.emini.dk Linux 2.4/2.6 Received: from ([192.38.9.232:3867] helo=gw2.emini.dk) by pb1.pair.com (ecelerity 2.1.1.3 r(11751M)) with ESMTP id 63/2A-23194-5F798C44 for ; Thu, 27 Jul 2006 06:39:51 -0400 Received: from [10.0.0.18] (palestine.intra.emini.dk [10.0.0.18]) by gw2.emini.dk (Postfix) with ESMTP id 36D27BD329; Thu, 27 Jul 2006 12:39:47 +0200 (CEST) Message-ID: <44C897F3.80905@emini.dk> Date: Thu, 27 Jul 2006 11:39:47 +0100 Organization: Emini A/S User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Matt W Cc: internals@lists.php.net, Dmitry Stogov , Ilia Alshanetsky References: <00d601c6af9d$c18f2d30$0201a8c0@pc1> <003701c6afb1$81b87720$6e02a8c0@thinkpad> <44C6205F.4090808@php.net> <00ed01c6b163$c3d40ad0$0201a8c0@pc1> In-Reply-To: <00ed01c6b163$c3d40ad0$0201a8c0@pc1> X-Enigmail-Version: 0.94.0.0 OpenPGP: id=157D0FA8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] memory_get_usage with new Memory Manager From: edink@emini.dk (Edin Kadribasic) Matt W wrote: > Hi Dmitry, Ilia, et al., > > Ilia, the Memory Manager is checking the *real* size against memory_limit, > so it's still "more accurate" even after the functions were changed to > report more like the old way. I still wonder how much difference there may > be between size and real_size as it gets close to the limit... > > After the changes, I see the usage difference after adding a variable, for > example, is slightly different than before, but I understand that's because > of counting overhead now or such. The old one just rounded the amount up to > a multiple of 8, I think... > > Something else I'd like to see changed... Does anyone think > memory_get_[peak_]usage() should *always* be available, regardless of > whether memory_limit is actually enabled? Using the Windows binaries at > least, I was devastated :-D that they were unavailable for experimenting, > etc. > > I don't see why not -- the function names IMO don't really suggest that > they're tied to memory_limit and all that's being saved by not having them > is a little overhead of updating the size/peak variables, right? > The reason is performance. It takes some processing time to keep accounting of memory usage and people don't using the feature do not feel like its worth slowing PHP down. Edin