From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19440 invoked by alias); 29 Jun 2009 09:45:12 -0000 Received: (qmail 19430 invoked by uid 22791); 29 Jun 2009 09:45:11 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 29 Jun 2009 09:45:04 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1MLDQ6-0001jd-Ei for gdb@sources.redhat.com; Mon, 29 Jun 2009 09:45:02 +0000 Received: from lvk-gate.cmc.msu.ru ([212.192.248.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jun 2009 09:45:02 +0000 Received: from vladimir by lvk-gate.cmc.msu.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jun 2009 09:45:02 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: -stack-list-locals and children Date: Mon, 29 Jun 2009 09:45:00 -0000 Message-ID: References: <629542d40906281203o3601025at573704e36ee80565@mail.gmail.com> <629542d40906290012p33c5504pde20ddcd7da3474a@mail.gmail.com> <200906291217.58961.vladimir@codesourcery.com> <629542d40906290230n4da6f347s1566847defb9a1c0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes 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 X-SW-Source: 2009-06/txt/msg00291.txt.bz2 Niko Sams wrote: > On Mon, Jun 29, 2009 at 10:17, Vladimir Prus wrote: >> [I assume you did not CC list accidentally, readding it back] >> >> On Monday 29 June 2009 you wrote: >> >>> >> Basic tests showed me that -var-create is relatively slow for large lists. >>> > >>> > How slow and how did you measure this? I would not expect variable objects to >>> > be considerably slower than printing the value in any other way. >>> I measured using -enable-timings. I did -var-create for a QStringList >>> with 1000 items, >>> took 0.6sec. >> >> This is the current problem with GDB -- it will always try to fetch all >> children, which has other problems besides performance. In particular, >> if you try to get children of an invalid object, gdb might never finish. >> Tom is planning to address this issue soon, and we'll be able to have >> incremental fetch of varobj children -- much like we have for stack >> frames in KDevelop already. > ok, I see. > When this is fixed -var-create should be faster? I'd imagine there be global changeable default number of children to fetch, say 10, so yes, it will be faster. >> Also, is -stack-list-locals any better here? I'd expect it to either have >> exactly the same performance problems, or ignore pretty-printing. If it >> is considerably faster while still reporting 1000 children, it's performance >> bug somewhere. > It's much faster. I get about 100 children in the value followed by .... Ah, hmm. Seems like CLI obeys 'set print elements' setting, then. When MI obeys it's own limit, I expect there to be no difference. - Volodya