From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31547 invoked by alias); 18 Dec 2003 04:04:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31539 invoked from network); 18 Dec 2003 04:04:08 -0000 Received: from unknown (HELO smtp10.atl.mindspring.net) (207.69.200.246) by sources.redhat.com with SMTP; 18 Dec 2003 04:04:08 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1AWpNw-0002B4-00; Wed, 17 Dec 2003 23:03:36 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 7D40D4B375; Wed, 17 Dec 2003 23:03:43 -0500 (EST) To: drow@mvista.com, jimb@redhat.com Subject: Re: new demangler Cc: carlton@kealia.com, gdb@sources.redhat.com Message-Id: <20031218040343.7D40D4B375@berman.michael-chastain.com> Date: Thu, 18 Dec 2003 04:04:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-12/txt/msg00247.txt.bz2 Jim Blandy writes: > When working on big C++ programs, I think I remember seeing that the > mangled and demangled names take up a *lot* of memory. I analyzed this recently. http://sources.redhat.com/ml/gdb/2003-12/msg00071.html http://sources.redhat.com/ml/gdb/2003-12/msg00092.html One specific thinko caused a lot of trouble for monotone, which is built with the boost libraries. But mozilla does not have any symbols which were affected by this bug, so memory size on mozilla probably didn't get any better with this bug fix. The new demangler has the same memory requirement has old demangler + bug fix (46 megabytes on monotone). But the new demangler runs a lot faster. Check out the difference in elapsed time between "H21" and "H30" in my table. gdb with old demangler + bug fix starts up in 9.46 seconds, and gdb with new demangler starts up in 3.03 seconds. > If that recollection is correct, it might be cool to have GDB store > the trees instead of the names, and throw a bcache at the nodes in > these demangled name trees, working from the leaves upward, to get > maximum sharing. I bet that would bring the memory requirements down > to something more closely resembling the actual number of classes, > methods, etc. in the program. How about quantifying gdb performance (space and time) on a real program first. There might not be a problem at all. Then look for some low-hanging fruit before pulling out the algorithmic guns. Michael C