From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19200 invoked by alias); 22 Dec 2014 02:04:43 -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 16497 invoked by uid 89); 22 Dec 2014 02:04:36 -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-f176.google.com Received: from mail-wi0-f176.google.com (HELO mail-wi0-f176.google.com) (209.85.212.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 22 Dec 2014 02:04:33 +0000 Received: by mail-wi0-f176.google.com with SMTP id ex7so6740049wid.9 for ; Sun, 21 Dec 2014 18:04:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.19 with SMTP id d19mr35798325wjr.48.1419213870272; Sun, 21 Dec 2014 18:04:30 -0800 (PST) Received: by 10.27.132.70 with HTTP; Sun, 21 Dec 2014 18:04:28 -0800 (PST) In-Reply-To: <20141221210151.GL12884@adacore.com> References: <83d27esisa.fsf@gnu.org> <83k31mqeoa.fsf@gnu.org> <83egrtr80o.fsf@gnu.org> <20141221210151.GL12884@adacore.com> Date: Mon, 22 Dec 2014 02:04:00 -0000 Message-ID: Subject: Re: [PATCH] symbol lookup cache From: Doug Evans To: Joel Brobecker Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00605.txt.bz2 On Sun, Dec 21, 2014 at 1:01 PM, Joel Brobecker wrote: >> 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. > > do you see the amount of data in the cache being all that much? Nope, and I've noted that in the code. Plus I recently gained back 40MB for free (16 * #minsyms) on one of my monster benchmarks. ref: https://sourceware.org/ml/gdb-patches/2014-11/msg00638.html We could spend 1/10 that on the cache (which would still be a rather large cache) and still be way ahead. > I haven't looked at your implementation, but for Ada, the cache is > updated when symbols are looked up, usually due to a user querying > something. So, I don't the cache to be all that big, and FWIW, > we have never even had to think of having a dynamic hash size. But, *if* one-size-fits-all *wasn't* working (*1), and I think I can reasonably assume we're agreed we're not there yet, then would you immediately go the route of providing a user option to allow changing the size, or first see if gdb could do better on its own? --- (*1): I'm only suggesting exploring dynamically adjusting the cache size (I realize you wrote hash size) *if* the data suggests we need it. IMO we're not there yet. But, and here's where the disagreement is (AFAICT), *if* we do get there, I'd rather see if gdb could do better on its own first, before adding a knob that the user has to tweak to get the desired performance.