From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28379 invoked by alias); 22 May 2013 19:20:06 -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 28368 invoked by uid 89); 22 May 2013 19:20:06 -0000 X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_SOFTFAIL autolearn=ham version=3.3.1 Received: from oproxy12-pub.bluehost.com (HELO oproxy12-pub.bluehost.com) (50.87.16.10) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Wed, 22 May 2013 19:20:02 +0000 Received: (qmail 1991 invoked by uid 0); 22 May 2013 19:20:01 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy12.bluehost.com with SMTP; 22 May 2013 19:20:01 -0000 Received: from [146.115.71.23] (port=59366 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UfEZs-0004wp-77; Wed, 22 May 2013 13:20:00 -0600 Message-ID: <1369250399.7209.164.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 19:20:00 -0000 In-Reply-To: <1369248335.7209.151.camel@homebase> References: <1368733335.4101.743.camel@pdsdesk> <51960329.2010802@redhat.com> <1369248335.7209.151.camel@homebase> 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/msg00103.txt.bz2 On Wed, 2013-05-22 at 14:45 -0400, Paul Smith wrote: > I've just got this case working now, so I'll look into what's going on > here more. OK, some quick info from strace: the fast GDB does about 400 system calls for the first iteration of the loop, in 0.024 seconds. It does 124 lseek(), 177 read(), and 101 rt_sigprocmask() system calls. The slow GDB does 20773 system calls in 4.4 seconds for the first iteration. It does 6914 lseek(), 13757 read(), and 101 rt_sigprocmask() system calls (plus the write of the results). The interesting thing is both versions are constantly seeking and reading to exactly the same location, over and over again. However GDB 4.6 does it many times more than GDB 7.5.1. For example, I get this combo: 14:51:34.423582 lseek(7, 26763264, SEEK_SET) = 26763264 <0.000004> 14:51:34.423609 read(7, "P\361\236\0\0\0\0\0`\361\236\0\0\0\0\0p\361\236\0\0\0\0\0\200\361\236\0\0\0\0\0"..., 4096) = 4096 <0.000015> 6838 times during the slow run (exact same offset value, exact same read request and response), and this one: 14:52:16.842408 lseek(14, 26763264, SEEK_SET) = 26763264 <0.000004> 14:52:16.842435 read(14, "P\361\236\0\0\0\0\0`\361\236\0\0\0\0\0p\361\236\0\0\0\0\0\200\361\236\0\0\0\0\0"..., 4096) = 4096 <0.000004> 48 times during the fast run. BTW I checked and those FDs are for the executable in both runs. I'm not sure why they're opened in a different order. Seems like it's time to do some test builds against the git tree.