From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16224 invoked by alias); 14 Dec 2009 19:33:15 -0000 Received: (qmail 16132 invoked by uid 22791); 14 Dec 2009 19:33:13 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 14 Dec 2009 19:33:08 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nBEJX7ru012320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 14 Dec 2009 14:33:07 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nBEJX2L7026932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Dec 2009 14:33:06 -0500 Message-ID: <4B2692EE.5090807@redhat.com> Date: Mon, 14 Dec 2009 19:33:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname References: <4B0707E7.5010308@uglyboxes.com> <20091120220927.GA9589@caradoc.them.org> <4B1EAD5C.6060708@redhat.com> In-Reply-To: <4B1EAD5C.6060708@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-12/txt/msg00185.txt.bz2 On 12/08/2009 11:47 AM, Keith Seitz wrote: > Yeah, this is *really* bad. Really, really bad. But this was just a an > attempt at "making it work." Now comes the "make it faster" part. I have > a few ideas about redundant calls and whatnot, but it will undoubtedly > take some real effort and refactoring to really make the best of this. > > I'm working on some performance numbers now with OpenOffice.org Writer > as Tom suggested. I'll follow up on this later in this thread when I > have some more data collected. Okay, so I have some performance numbers for my box using CVS HEAD patched and unpatched with my dwarf2_physname patches. Yes, --readnow and things like "info func" and "info types" will take a big performance hit (really big right now). So, without further ado... I did three tests, all with OpenOffice.org Writer, as Tom suggested. So when you see $PID, you'll know what PID that's for. 1. time ./gdb -nx -q --batch-silent --pid $PID 2> /dev/null HEAD: real 1m14.906s 0m14.517s 0m12.229s 0m12.669s 0m12.638s user 0m19.050s 0m11.985s 0m11.770s 0m11.738s 0m11.754s sys 0m1.998s 0m0.484s 0m0.448s 0m0.437s 0m0.431s dwarf2_physname: real 1m6.761s 0m12.143s 0m12.070s 0m12.098s 0m12.128s user 0m18.863s 0m11.710s 0m11.652s 0m11.695s 0m11.683s sys 0m1.954s 0m0.420s 0m0.390s 0m0.390s 0m0.413s 2. time ./gdb -nx -q --batch-silent --pid $PID -ex "thread apply all bt full" 2> /dev/null HEAD: real 1m9.236s 0m12.739s 0m12.619s 0m12.613s 0m12.565s user 0m19.059s 0m12.178s 0m12.170s 0m12.166s 0m12.102s sys 0m1.883s 0m0.433s 0m0.440s 0m0.434s 0m0.456s dwarf2_physname: real 1m8.355s 0m13.276s 0m13.211s 0m13.208s 0m13.138s user 0m19.863s 0m12.679s 0m12.750s 0m12.708s 0m12.708s sys 0m0.978s 0m0.465s 0m0.436s 0m0.422s 0m0.425s 3. time ./gdb -nx -q --batch-silent --readnow --pid $PID 2> /dev/null HEAD: real 10m42.371s 6m57.499s 6m2.538s 7m50.482s 6m46.206s user 1m43.927s 1m40.768s 1m40.768s 1m40.673s 1m41.129s sys 0m9.349s 0m7.875s 0m7.038s 0m8.751s 0m7.552s dwarf2_realname: real 774m37.623s user 3m48.010s sys 0m14.745s As you can see, --readnow (and by extrapolation "info func" and "info type") take an enormous performance hit. The dwarf2_physname patch as it currently exists, though, appears to have a pretty minimal impact on performance for more "normal" or "mundane" usage. In other news, I've tested linux native using STABS, and there are two test files that show a total of five regressions, which I am digging into. [I've eliminated another five failures because they also exist as "failures" in the DWARF case (the library is still using DWARF!).] As I'm sure we all know, STABS and C++ are such horrible bedfellows to begin with... Keith