From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23751 invoked by alias); 24 Nov 2008 21:54:58 -0000 Received: (qmail 23596 invoked by uid 22791); 24 Nov 2008 21:54:58 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 21:54:18 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id B93652A003; Mon, 24 Nov 2008 13:54:08 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost3.vmware.com (Postfix) with ESMTP id AD683C9AA9; Mon, 24 Nov 2008 13:54:08 -0800 (PST) Message-ID: <492B2255.4080206@vmware.com> Date: Tue, 25 Nov 2008 08:48:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: Re: [RFA] Add optional argument to "info threads" command References: <4928BC24.5020600@vmware.com> <200811240308.49485.pedro@codesourcery.com> <492AFAE8.4040405@vmware.com> <200811241924.14165.pedro@codesourcery.com> In-Reply-To: <200811241924.14165.pedro@codesourcery.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-11/txt/msg00671.txt.bz2 Pedro Alves wrote: > On Monday 24 November 2008 19:05:12, Michael Snyder wrote: >> Well, all your observations are correct -- but the same thing >> also happens if you merely switch the thread of focus using the >> "thread" command. >> >> I do think that prune-threads and target_find_new_threads >> are being called too aggressively from somewhere, but it >> isn't directly from info_threads_command. > > It's inside print_thread_info, and IIUC, you're calling it > on each of the ids in range? > >> I think this is a separate, pre-existing problem that this patch >> helps to reveal. > > I'm thinking about the case where you have 200 threads, and you > do 'info threads 40-45'. > > That'll do 15 prune_threads, target_find_new_threads and > frame restores. That'll be around '14 * (200 + 200 + 1)' > roundtrips extra at least instead of the current (200 + 200). > > The worst case, is of course, if you do 'info threads 1-200'. > Then you'll have '199 * (200 + 200 + 1)' extra target > roundtrips compared to plain 'info threads'. That's around > 80000? Unless I'm missing something. > > Isn't this the same reasoning behind having thread_apply_command > and thread_apply_all implementations, instead of having one call > into the other? OK -- are you suggesting to abstract print_thread_info out into two separate functions?