From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17464 invoked by alias); 11 Aug 2014 14:57:46 -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 17453 invoked by uid 89); 11 Aug 2014 14:57:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-HELO: ms9smtp.webland.ch Received: from ms9.webland.ch (HELO ms9smtp.webland.ch) (92.43.217.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 11 Aug 2014 14:57:44 +0000 Received: from macserver.private ([77.57.22.1]) by ms9smtp.webland.ch (Webland Mail Server v. 10.4.1) with ASMTP id 201408111657386315 for ; Mon, 11 Aug 2014 16:57:38 +0200 Received: from localhost (localhost [127.0.0.1]) by macserver.private (Postfix) with ESMTP id 530021F1B2BA; Mon, 11 Aug 2014 16:57:37 +0200 (CEST) Received: from macserver.private ([127.0.0.1]) by localhost (macserver.private [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghN43HlEbirb; Mon, 11 Aug 2014 16:57:29 +0200 (CEST) Received: from [192.168.1.66] (unknown [192.168.1.66]) by macserver.private (Postfix) with ESMTP id BA2871F1B2AF for ; Mon, 11 Aug 2014 16:57:29 +0200 (CEST) Message-ID: <53E8D9D0.9010508@indel.ch> Date: Mon, 11 Aug 2014 14:57:00 -0000 From: Raphael Zulliger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: Re: Performance issue of -var-list-children on structs with many members and remote targets References: <53E47B59.3060700@indel.ch> <53E4A6F8.1000905@codesourcery.com> In-Reply-To: <53E4A6F8.1000905@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg00014.txt.bz2 On 08/08/2014 12:31 PM, Yao Qi wrote: > On 08/08/2014 03:25 PM, Raphael Zulliger wrote: >> Now my simple question: Couldn't GDB be tweaked to get the struct member >> values by just one call (because members within a struct are guaranteed >> to be consecutive, aren't they?): >> >> 499,883 38-var-list-children var2.public >> 499,884 &"Sending packet: $m601050,24#??" >> >> I guess this would dramatically increase overall performance. >> >> I would really like to see such an improvement in GDB. Therefore, I'd be >> very happy to hear your thoughts and suggestion. Thinks like: What >> problems (e.g. border cases) could arise when implementing this? Where >> to start in the GDB code for such a modification? Or do there exist any >> GDB switches to improve performance on such operations? etc... > I have no idea how to merge multiple reads into one. Thanks for your response! I guess you are aware of the fact that -data-evaluate-expression is already getting the data in the most efficient way, see e.g.: -data-evaluate-expression --thread 1 --frame 0 g_s &"Sending packet: $m601050,18#2e..." &"Packet received: 000000000000f03f00000000000000000000000000000000\n" ^done,value="{a = 1, b = 0, c = 0}" Couldn't we do the same during a '-var-update' for a struct like varobj and let it propagate the values to it's children, instead of letting the children update their values? An implementation could probably indeed be done with a cache system, as suggested by you below. Then the "only" changes would be to implement that cache and to update struct-like varobj *before* traversing their children. Would something like that make sense? > > Cache is used in GDB to read code and stack from target, which > increases performance to some extent (See target_read_code and > target_read_stack). However, cache is NOT used to read general data. > Probably, you can make general data reading use cache too. In our use case, we're debugging real-time systems in which (global) data often changes at a rapid rate and thus the cache alone wouldn't help much.