From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18526 invoked by alias); 2 Sep 2004 17:15:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 18510 invoked from network); 2 Sep 2004 17:15:06 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.10) by sourceware.org with SMTP; 2 Sep 2004 17:15:06 -0000 Received: (qmail 14697 invoked from network); 2 Sep 2004 17:15:05 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 2 Sep 2004 17:15:05 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Thu, 2 Sep 2004 10:15:05 -0700 To: Jan Hubicka Cc: Matt Austern , gcc-patches@gcc.gnu.org, stevenb@suse.de, rth@redhat.com Subject: Re: Better memory statistics, take 2 References: <20040902161203.GF22834@atrey.karlin.mff.cuni.cz> <87eklk1vy6.fsf@codesourcery.com> <20040902164542.GG22834@atrey.karlin.mff.cuni.cz> From: Zack Weinberg Date: Thu, 02 Sep 2004 17:15:00 -0000 In-Reply-To: <20040902164542.GG22834@atrey.karlin.mff.cuni.cz> (Jan Hubicka's message of "Thu, 2 Sep 2004 18:45:42 +0200") Message-ID: <87acw81tk6.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-09/txt/msg00230.txt.bz2 Jan Hubicka writes: >> On Sep 2, 2004, at 9:23 AM, Zack Weinberg wrote: >> >> >Jan Hubicka writes: >> > >> >>Hi, >> >>here is updated version of patch I sent while reducing memory for GCC >> >>3.4, it is quite usefull now again... >> >> >> >>Hi, this patch improves the per-line statistics by tracking down >> >>each allocated entity to figure out whether it will be freed, >> >>garbage collected or leaked. To rule out ggc_freed values is pretty >> >>important as these are much cheaper, >> >... >> > >> >Please do timing tests before submitting any changes. In my >> >experience ggc_free is *not* cheaper, it is by itself such an >> >expensive operation that we don't actually gain anything over >> >letting the garbage collector do its job. > > My experience is that you need to free quite a lot of memory to see gain > (ie you need to avoid at leat one GGC run). For Gerald's testcase I > actually measured slight change in execution time with both changes (ie > one GGC run, but it is because my memory setup is definitly on the > corner between 22 and 23 GGC runs) That makes sense. Note though that the current memory-pressure heuristics don't run the collector at all for small to medium-sized input. > This patch is not adding any ggc_free, just making analysis prettier. I > have some extra patches dependent on the framework (ie I use it to > detect leaks where we keep pointer to something local accidentally and > it was usefull enought to reduce peak memory usage of combine.c > compilation from 12MB to 2.8MB.) Yes. I wasn't clear enough: I am not objecting to this patch, only cautioning you not to assume that sprinkling ggc_free calls through the compiler will speed anything up. >> What this does mean is that if we know a data structure will be >> temporary, we shouldn't use ggc_free or ggc_anything. > > Yes, where convenient, I am trying to get out of GGC completely. Agree, use of xmalloc or obstacks for data with a well-defined lifetime is a good move. zw