From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90826 invoked by alias); 24 Mar 2016 03:14:58 -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 90795 invoked by uid 89); 24 Mar 2016 03:14:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=rough, significantly, promising, super X-HELO: mail-qk0-f174.google.com Received: from mail-qk0-f174.google.com (HELO mail-qk0-f174.google.com) (209.85.220.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 24 Mar 2016 03:14:54 +0000 Received: by mail-qk0-f174.google.com with SMTP id o6so15067926qkc.2 for ; Wed, 23 Mar 2016 20:14:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qlIeqrSv5adCUAU49/AuiQzuK4EOZNi08ThEOmr8XtE=; b=jbIRX2WQzjBrVUBusbSRYmT4+FDLuDUm78SNZS3Dhj0fWx5k3U4ocGWTrm/zpjD/1u B4XzndRfyfCG15SKsM5SMxjJZOSjSj3P7190IwcwTmSbeu5bTAKtbkbCxC61wWQyYMJG KQtcDUTlRMfWTYpF84y8xkyUnQSuWRQkoduPoHC2Mhsi1mCCFC+LAmI2y4+WbIbGo/h2 Qe/DLyqqEhxcPmZz5YRTjuZXV6kGtXUaEp8CIe3SdYfc8oYoIiUKES1RYUskHS6x4iDA /K9COjpq93Rx7HHilEu+jvYRBAGlZ4Z2G/PDMAmUQaYqIcR4WADIzI8762Abu0QyOeGa mEbA== X-Gm-Message-State: AD7BkJL1vT1PzEKwcLV33elBEUHwSkWsBQKNRcOkJheSsy/4ytO12YSog6rdvRlg1zH5sVmob+phqEV7/VRPww== X-Received: by 10.55.54.14 with SMTP id d14mr7670538qka.64.1458789292302; Wed, 23 Mar 2016 20:14:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.130 with HTTP; Wed, 23 Mar 2016 20:14:32 -0700 (PDT) In-Reply-To: <56F34041.2000301@redhat.com> References: <56F168D7.9050405@redhat.com> <56F16F8F.9050404@redhat.com> <56F1759F.3070100@redhat.com> <56F17A23.90909@redhat.com> <56F2DF69.9030908@redhat.com> <56F2F31F.4000104@redhat.com> <56F34041.2000301@redhat.com> From: Yichao Yu Date: Thu, 24 Mar 2016 03:14:00 -0000 Message-ID: Subject: Re: JIT debugging (Attach and speed) To: Pedro Alves Cc: gdb@sourceware.org, Paul Pluzhnikov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00046.txt.bz2 > The prototype patch below (also in users/palves/jit-speedup, along > with the attach fixes), simply delays computing a frame until > it's necessary, and it cuts down the time for: (The patch seems to have some white space breakage but the branch works great.) > gdb ---args ./testsuite/outputs/gdb.base/jit/jit-main ./testsuite/outputs/gdb.base/jit/jit-solib.so 2000 > > from "takes too long so I canceled it" minutes, to around 2 seconds, for me. There's indeed a huge improvement. The test I was using with ~2000 JIT objects goes drops from ~400s to 7.5s (~3s without gdb). However a rough scaling test suggests that the scaling is still ~O(n^2) 20k JIT objects takes ~500s (~130s without gdb). It seems that the master was actually super quadratic (if this is a word) when dealing with multiple JIT objects. > Having a pending breakpoint that is never resolved slows things down > significantly again though... The perf profile shows that breakpoint_re_set > ends up calling parse_linespec which wants the selected block, which wants > the selected frame, and then we're back at the same... Maybe we > could reconsider how pending breakpoints are re-parsed, and which > context they're parsed in. Not sure. > > Still, very promising. > Indeed. It's already so much better.