From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19880 invoked by alias); 17 May 2013 10:15:11 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 19869 invoked by uid 89); 17 May 2013 10:15:10 -0000 X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 17 May 2013 10:15:10 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4HAF6SF001883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 06:15:07 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4HAF5Yi023071; Fri, 17 May 2013 06:15:06 -0400 Message-ID: <51960329.2010802@redhat.com> Date: Fri, 17 May 2013 10:15:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: psmith@gnu.org CC: gdb@sourceware.org Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores? References: <1368733335.4101.743.camel@pdsdesk> In-Reply-To: <1368733335.4101.743.camel@pdsdesk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00077.txt.bz2 On 05/16/2013 08:42 PM, Paul Smith wrote: > Hi all. Is anyone aware of an issue with a big slowdown running macros > on core files? I'm not sure if this is related to GCC 4.8 or GDB 7.6, > or what, but I'm seeing a 4x or more slowdown when running macros on > core files from previous releases. > > Running against a live process is the same speed as before. Wow. If you haven't yet, it'd make sense to try process vs core at the exact same spot: $ gdb myprogram (gdb) run ... (gdb) mymacro (gdb) gcore mycore (gdb) quit $ gdb myprogram -c mycore (gdb) mymacro > Against a core file it takes a second or longer per iteration of this > loop! FWIW, the class this macro operates on is very large and contains > a lot of data per object. > > Any ideas? Is there a handy way to tell where the slowdown is happening > here? I'm really surprised. If anything, I'd expect cores to be marginally faster. I suggest git bisecting gdb looking. Maybe you'll find the culprit easily that way. > Should we just drop back to DWARF2 or DWARF3 (I haven't checked > if that will help tho)? Ideally no, of course. Let us know if that indeed helps. Using DWARF < 4 should make it easier to git bisect the culprit, as you can then start bisecting before the patches that added support for DWARF4. -- Pedro Alves