From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5082 invoked by alias); 28 May 2013 17:11: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 5066 invoked by uid 89); 28 May 2013 17:11:06 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1 Received: from mail-vb0-f43.google.com (HELO mail-vb0-f43.google.com) (209.85.212.43) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 28 May 2013 17:11:00 +0000 Received: by mail-vb0-f43.google.com with SMTP id e12so3337061vbg.30 for ; Tue, 28 May 2013 10:10:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SC99tsvFCJdlrFEn5rLsoKcft7h8LCzbVqvRoqUrmjQ=; b=H55nE/87EguC/1ZbAhTsrMwkMtJporQ2wnCZrD7ADEA2q7Eek9e8Pwn1ejduN2Rxhx JevOyUyoBPMu7pdj3Lund5QSqQYPob4LN/JFs65wm5R6HEmmuBNpNxQTPKRqPtIqmmRN Ys9uEuqLxs8m4ZsNgtwArfSDJlWCWwOCKsyEfW3Ry2VqrD5m5aWuLULBB6TVd+1yoJws e8/hxbvqrcbDkKyNoa1Zrz+6bdbHoGNg/g9zr4I9m/EbcQRcA+QJHK2xfXWP8n/qY/0x ySDeA3hCBBTLUL//s9GIwa4NXZiDVbMlR7XfcuQMRqpiQuxWeiJpuvTNoB9vZ4//Kfn6 Ca6Q== MIME-Version: 1.0 X-Received: by 10.58.37.165 with SMTP id z5mr18630874vej.12.1369761058526; Tue, 28 May 2013 10:10:58 -0700 (PDT) Received: by 10.220.54.206 with HTTP; Tue, 28 May 2013 10:10:58 -0700 (PDT) In-Reply-To: <1369284101.7209.197.camel@homebase> References: <1368733335.4101.743.camel@pdsdesk> <51960329.2010802@redhat.com> <1369248335.7209.151.camel@homebase> <1369250399.7209.164.camel@homebase> <87wqqqg4e2.fsf@fleche.redhat.com> <1369264444.7209.184.camel@homebase> <1369284101.7209.197.camel@homebase> Date: Tue, 28 May 2013 17:11:00 -0000 Message-ID: Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores? From: Doug Evans To: psmith@gnu.org Cc: Tom Tromey , Pedro Alves , gdb Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnAjHXJQIKYzoMF3QgeYnPyPvU/fMUssvakWF2f8mIzUb0siNNDMKINGGBe35ij+hzDsndkf+7a/krMiS7RpNScfWR1YzIMmwlxewJq3cJfw1bUOqmcDPh6EOHoE0lOfRkerB8H5ZR6pbs74Oa0kn/t13mfe3tpAQpeigDah4Bc34p2Hxov20cO9t/ZIPtc2jxMB+Uc X-SW-Source: 2013-05/txt/msg00122.txt.bz2 On Wed, May 22, 2013 at 9:41 PM, Paul Smith wrote: > On Wed, 2013-05-22 at 19:44 -0700, Doug Evans wrote: >> On Wed, May 22, 2013 at 4:14 PM, Paul Smith wrote: >> > On Wed, 2013-05-22 at 14:12 -0600, Tom Tromey wrote: >> > And the top 10 users in the slow instance: >> > >> > Each sample counts as 0.01 seconds. >> > % cumulative self self total >> > time seconds seconds calls ms/call ms/call name >> > 23.99 14.26 14.26 69374700 0.00 0.00 lookup_partial_symbol >> > 23.77 28.39 14.13 784950557 0.00 0.00 strcmp_iw >> > 11.74 35.37 6.98 763482775 0.00 0.00 symbol_get_demangled_name >> > 7.23 39.67 4.30 819480663 0.00 0.00 symbol_natural_name >> > 7.22 43.96 4.29 373483 0.01 0.01 lookup_symbol_aux_psymtabs >> > 5.60 47.29 3.33 777569558 0.00 0.00 symbol_matches_domain >> > 4.98 50.25 2.96 819477261 0.00 0.00 symbol_search_name >> > 2.46 51.71 1.46 34366788 0.00 0.00 strcmp_iw_ordered >> > 1.51 52.61 0.90 4 225.00 225.00 fprintf_symbol_filtered >> > 1.46 53.48 0.87 15316453 0.00 0.00 xstrdup >> >> Looks rather familiar. :-) > > Hi Doug; I'm not sure what that means; is there already a bug filed > about this? Is it a known issue? > > I tested with the latest code on master in the Git repo earlier today > and saw the same slow behavior, so it's not been fixed since 7.6 was > released. Hi. That was more an off-the-cuff comment as I've done a ton of profiling and reading of gdb's symbol table code (one can only do it in stages - it can get quite depressing). And I can't offhand explain why you *only* see the slowdown with a core file and not with a live executable. I wasn't aware of the problems with the 12/11/16 patch you found. I've submitted a minor improvement - IMO the real fix will involve a lot more effort - gdb's symbol handling is obtuse enough that it's easy to introduce performance regressions or even overlook basic performance problems.