From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9772 invoked by alias); 5 Nov 2009 17:28:56 -0000 Received: (qmail 9762 invoked by uid 22791); 5 Nov 2009 17:28:56 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Nov 2009 17:28:51 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id B16532BAC82; Thu, 5 Nov 2009 12:28:49 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZwsHs-2QEKz5; Thu, 5 Nov 2009 12:28:49 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 75F432BAB6B; Thu, 5 Nov 2009 12:28:49 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 963A3F5905; Thu, 5 Nov 2009 09:28:39 -0800 (PST) Date: Thu, 05 Nov 2009 17:28:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: save lots of memory Message-ID: <20091105172839.GI4557@adacore.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00088.txt.bz2 > This patch changes gdb so that such names are not copied. This saves a > lot of memory. For example, I ran OO.o writer and attached to it with > gdb (I have full debug info installed for OO.o and all its > dependencies). As discussed on IRC, I looked at the patch, and I think it is pretty nice. The downside for the other formats seems reasonably small and we have the options suggested by Tom in case we need to reclaim the extra memory being consumed with the current approach. I'm looking forward to measuring the impact on memory and performance with one of the bigger apps we have in house :-). -- Joel