From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29784 invoked by alias); 23 Jan 2015 16:57:07 -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 29770 invoked by uid 89); 23 Jan 2015 16:57:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f43.google.com Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 23 Jan 2015 16:57:02 +0000 Received: by mail-wg0-f43.google.com with SMTP id y19so8609044wgg.2 for ; Fri, 23 Jan 2015 08:57:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.182.8 with SMTP id ea8mr5659714wic.48.1422032219968; Fri, 23 Jan 2015 08:56:59 -0800 (PST) Received: by 10.27.39.198 with HTTP; Fri, 23 Jan 2015 08:56:59 -0800 (PST) In-Reply-To: <83zj99sbgk.fsf@gnu.org> References: <1417094168-25868-1-git-send-email-gbenson@redhat.com> <1417094168-25868-4-git-send-email-gbenson@redhat.com> <20141210122233.GA7299@blade.nx> <21671.20308.262958.475080@ruffy2.mtv.corp.google.com> <20150107084255.GA17867@blade.nx> <21680.36641.315766.209208@ruffy2.mtv.corp.google.com> <83a91r6lbd.fsf@gnu.org> <20150115153930.GA14900@blade.nx> <83h9vhu7k8.fsf@gnu.org> <83zj99sbgk.fsf@gnu.org> Date: Fri, 23 Jan 2015 20:28:00 -0000 Message-ID: Subject: Re: [PATCH 3/3 v2] Implement completion limiting From: Doug Evans To: Eli Zaretskii Cc: Gary Benson , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00659.txt.bz2 On Fri, Jan 23, 2015 at 8:34 AM, Eli Zaretskii wrote: >> Date: Fri, 23 Jan 2015 08:14:15 -0800 >> From: Doug Evans >> Cc: Gary Benson , >> "gdb-patches@sourceware.org" >> >> The patch stops searching when the limit is reached. >> It doesn't keep looking for at least one more to see if there are any more. >> Is this absolutely critical? Why? > > Because if the user sets the maximum at N, she wants to see N > elements, and if there are exactly N, she shouldn't get any warnings, > IMO. How often will there be exactly N? And in that particular and massively rare case, once gdb has found N, how much extra work will be performed searching the entire executable and all its shared libraries just to verify there are in fact no more completions? [because that's what has to happen if we're to avoid printing *any* message] The user waits 5 minutes for the entire list and gets her 200 completions, and wonders why it took so long. Then she digs a bit deeper and finds out they were found in the first 5 seconds. Ugh. I don't see the benefit of going to the trouble of avoiding printing any message when there are exactly N completions. If there are exactly N completions and I see the message, no big deal.