From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5490 invoked by alias); 22 May 2013 18:50:34 -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 5481 invoked by uid 89); 22 May 2013 18:50:34 -0000 X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from oproxy14-pub.unifiedlayer.com (HELO oproxy14-pub.unifiedlayer.com) (67.222.51.224) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Wed, 22 May 2013 18:50:33 +0000 Received: (qmail 19544 invoked by uid 0); 22 May 2013 18:45:37 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy14.unifiedlayer.com with SMTP; 22 May 2013 18:45:37 -0000 Received: from [146.115.71.23] (port=59192 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UfE2a-00029i-IO; Wed, 22 May 2013 12:45:36 -0600 Message-ID: <1369248335.7209.151.camel@homebase> Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores? From: Paul Smith Reply-To: psmith@gnu.org To: Pedro Alves Cc: gdb@sourceware.org Date: Wed, 22 May 2013 18:50:00 -0000 In-Reply-To: <51960329.2010802@redhat.com> References: <1368733335.4101.743.camel@pdsdesk> <51960329.2010802@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul@mad-scientist.us} X-SW-Source: 2013-05/txt/msg00102.txt.bz2 On Fri, 2013-05-17 at 11:15 +0100, Pedro Alves wrote: > > 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. Sorry for the delay. Getting a repro case was harder than it seemed initially... just running "kill -9" on the process wasn't enough, or didn't crash at the right spot, or something. We had to induce a failure through a particular assert(). However, now I have a core file and executable built with my local copy of GDB 4.8.0. If I run the macro using a locally-built copy of GDB 7.5.1, then I get this behavior: $ time gdb-7.5.1 -c core.30095 -x macros.gdb myprog \ -ex "frame 4" -ex "ptracelog master->traceLog" -ex "q" ...prints 200 trace log lines... real 0m2.811s user 0m2.768s sys 0m0.028s so that's good stuff. Now I try it with GDB 7.6, compiled locally using the identical configure/etc. commands, and I get this behavior: $ time gdb-7.6 -c core.30095 -x macros.gdb myprog \ -ex "frame 4" -ex "ptracelog master->traceLog" -ex "q" ...prints 200 trace log lines... real 11m51.113s user 11m46.324s sys 0m2.168s That's... not as good :-p. I've just got this case working now, so I'll look into what's going on here more.