From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22836 invoked by alias); 8 Jun 2006 03:50:40 -0000 Received: (qmail 22828 invoked by uid 22791); 8 Jun 2006 03:50:40 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 08 Jun 2006 03:50:37 +0000 Received: from kahikatea.snap.net.nz (p202-124-112-34.snap.net.nz [202.124.112.34]) by viper.snap.net.nz (Postfix) with ESMTP id 49CBD76BA82; Thu, 8 Jun 2006 15:21:34 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 90C551D3550; Thu, 8 Jun 2006 15:20:49 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17543.38799.972990.666337@kahikatea.snap.net.nz> Date: Thu, 08 Jun 2006 06:22:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI: -var-update performance In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.0.50.20 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00051.txt.bz2 Vladimir Prus writes: > > Hi, > I'm running into a case where -var-update takes about 2 seconds to execute. > There's quite a lot of varobjs, but 2 seconds is beyond any expectation. > > Here's the profile: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls Ts/call Ts/call name > 22.44 70.23 70.23 lookup_partial_symbol > 19.65 131.72 61.49 > lookup_minimal_symbol_by_pc_section > 15.80 181.16 49.44 > basic_lookup_transparent_type > 10.39 213.67 32.51 find_pc_sect_psymtab > 5.25 230.11 16.45 strcmp_iw_ordered > 2.50 237.93 7.82 find_pc_sect_section > 1.96 244.06 6.13 dwarf2_frame_find_fde > 1.88 249.94 5.89 strcmp_iw > 1.21 253.72 3.78 read_partial_die > 1.02 256.90 3.18 > lookup_symbol_aux_psymtabs > 0.97 259.94 3.04 symbol_search_name > > > > Any ideas what's up? Should I try to rebuild gdb with --enable-profiling to > get call graph? More generally, I think we should add a timestamp field, like Apple have, so we can see which MI commands are using most of the time e.g. From: Jason Molenda Subject: Re: How does GDB/MI give the current frame Date: Thu, 15 Jul 2004 13:04:20 -0700 (gdb) -interpreter-exec console-quoted up ~"#2 0x000321f4 in gdb_main (args=0xbffff620) at ../../gdb/src/gdb/main.c:851\n" ~"851\t catch_errors (captured_main, args, \"\", RETURN_MASK_ALL);\n" ^done,MI_HOOK_RESULT=[HOOK_TYPE="frame_changed",frame="2"],time= {wallclock="0.00620",user="0.00323",system="0.00283",start="1089921236.3 59009",end="1089921236.365212"} (gdb) -- Nick http://www.inet.net.nz/~nickrob