From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19179 invoked by alias); 21 Dec 2014 18:51:25 -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 19167 invoked by uid 89); 21 Dec 2014 18:51:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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-wi0-f175.google.com Received: from mail-wi0-f175.google.com (HELO mail-wi0-f175.google.com) (209.85.212.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 21 Dec 2014 18:51:21 +0000 Received: by mail-wi0-f175.google.com with SMTP id l15so6298998wiw.2 for ; Sun, 21 Dec 2014 10:51:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.90.16 with SMTP id bs16mr24274801wib.4.1419187878127; Sun, 21 Dec 2014 10:51:18 -0800 (PST) Received: by 10.27.132.70 with HTTP; Sun, 21 Dec 2014 10:51:17 -0800 (PST) In-Reply-To: <83egrtr80o.fsf@gnu.org> References: <83d27esisa.fsf@gnu.org> <83k31mqeoa.fsf@gnu.org> <83egrtr80o.fsf@gnu.org> Date: Sun, 21 Dec 2014 18:51:00 -0000 Message-ID: Subject: Re: [PATCH] symbol lookup cache From: Doug Evans To: Eli Zaretskii Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00602.txt.bz2 On Sat, Dec 20, 2014 at 7:33 PM, Eli Zaretskii wrote: >> Date: Sat, 20 Dec 2014 13:04:01 -0800 >> From: Doug Evans >> Cc: "gdb-patches@sourceware.org" >> >> On Sat, Dec 20, 2014 at 11:55 AM, Eli Zaretskii wrote: >> >> Date: Sat, 20 Dec 2014 11:14:39 -0800 >> >> From: Doug Evans >> >> Cc: "gdb-patches@sourceware.org" >> >> >> >> > Btw, I wonder if this should be a user option, not a "maint" option. >> >> > The heuristics used to determine the cache size tend to be wrong in >> >> > some rare corner cases, so letting the user override this should be a >> >> > good thing, I think. >> >> >> >> The thought is the fewer knobs the user needs the better, >> > >> > We are way past the point where this ideal was achievable. You can >> > stop worrying about that. With the gazillion knobs we have already, >> > one more doesn't change anything. >> >> There isn't so much an ideal as a process that should be followed. >> I still want to vet every new knob that I feel needs vetting. > > And the considerations, such as those I described, by others that > users might want this option -- do these have any bearing on your > decisions? IOW, is there any hope to convince you in these matters? I'm not in any rush to add such an option. For example, if gdb can adequately dynamically adjust the size of the cache on its own then the need for such an option is much less (and users would be even happier than having to manually adjust the cache size on their own). Let's first verify the efficacy of the cache, collect some data, and go from there. And the next step after that, besides improving the efficiency of the cache (*1), if the data suggests it, is I think to explore dynamically adjusting the cache size. And if, after that, there are still some important cases where gdb can't do a good enough job on its own, *then* I'd be happy to add some knobs to control the cache size. Maybe the knob we will want is not so much to control the cache size but how it grows. ---- (*1): E.g., one can imagine adding support to not kick out frequently used items, and there are various, umm, ways to do this. [Bad pun intended - just trying to keep it light. :-)]