From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16939 invoked by alias); 20 Oct 2014 21:44:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 16925 invoked by uid 89); 20 Oct 2014 21:44:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 20 Oct 2014 21:44:15 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9KLiEdZ006241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 20 Oct 2014 17:44:14 -0400 Received: from host2.jankratochvil.net (ovpn-116-79.ams2.redhat.com [10.36.116.79]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9KLiBAf014875 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 20 Oct 2014 17:44:13 -0400 Date: Mon, 20 Oct 2014 21:44:00 -0000 From: Jan Kratochvil To: gdb-patches@sourceware.org Subject: [patch 0/2] Accelerate symbol lookups 15x Message-ID: <20141020214410.GA22011@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00523.txt.bz2 Hi, this patchset has been developed+tested only on top of [patchv2] Fix 100x slowdown regression on DWZ files https://sourceware.org/ml/gdb-patches/2014-10/msg00031.html While this patchset is technically independent the GDB performance and memory requirements would not make testing of this patchset possible. Originally I expected with the patch above (fixing backtrace performance) even the sluggish interactive GDB performance would get fixed. It was not fixed. During debugging I get 10-30 seconds for a response to simple commands like: (gdb) print vectorvar.size() With this patch the performance gets to 1-2 seconds which is somehow acceptable. The problem is that dwarf2_gdb_index_functions.lookup_symbol (quick_symbol_functions::lookup_symbol) may return (and returns) NULL even for symbols which are present in .gdb_index but which can be found in already expanded symtab. But searching in the already expanded symtabs is just too slow when there are 400000+ expanded symtabs. There would be needed some single global hash table for each objfile so that one does not have to iterate all symtabs. Which .gdb_index could perfectly serve for, just its lookup_symbol() would need to return authoritative yes/no answers. Even after such fix these two simple patches are useful for example for non-.gdb_index files. One can reproduce the slugging interactive GDB performance with: #include using namespace std; string var; class C { public: void m() {} }; int main() { C c; c.m(); return 0; } g++ -o slow slow.C -Wall -g $(pkg-config --libs gtkmm-3.0) gdb ./slow -ex 'b C::m' -ex 'maintenance set per-command space' -ex 'maintenance set per-command symtab' -ex 'maintenance set per-command time' -ex r [...] (gdb) p Display all 183904 possibilities? (y or n) n (gdb) p/r var $1 = {static npos = , _M_dataplus = {> = {<__gnu_cxx::new_allocator> = {}, }, _M_p = 0x3a4db073d8 ""}} Command execution time: 20.023000 (cpu), 20.118665 (wall) ^^^^^^^^^ Space used: 927997952 (+0 for this command) #symtabs: 186099 (+0), #primary symtabs: 21573 (+0), #blocks: 290353 (+0) For a non-trivial application with all symtabs expanded it takes 113 seconds. Benchmark on non-trivial application without 'p ': Command execution time: 0.496000 (cpu), 0.496882 (wall) --- both fixes Command execution time: 0.899000 (cpu), 0.908062 (wall) --- just lookup_symbol_aux_objfile fix Command execution time: 3.492000 (cpu), 3.491791 (wall) --- FSF GDB HEAD Benchmark on non-trivial application with 'p ': Command execution time: 7.373000 (cpu), 7.395095 (wall) --- both fixes Command execution time: 13.572000 (cpu), 13.592689 (wall) --- just lookup_symbol_aux_objfile fix Command execution time: 113.036000 (cpu), 113.067995 (wall) --- FSF GDB HEAD No regressions on {x86_64,x86_64-m32,i686}-fedora21pre-linux-gnu in standard and .gdb_index-enabled runs. Neither of the patches should cause any visible behavior change. Jan