From: Doug Evans <xdje42@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] symbol lookup cache
Date: Sun, 21 Dec 2014 18:51:00 -0000 [thread overview]
Message-ID: <CAP9bCMRNnQsMB5i962mzT_-H_s+in09A7rZiC6KkQ2NfFzJJjg@mail.gmail.com> (raw)
In-Reply-To: <83egrtr80o.fsf@gnu.org>
On Sat, Dec 20, 2014 at 7:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sat, 20 Dec 2014 13:04:01 -0800
>> From: Doug Evans <xdje42@gmail.com>
>> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>>
>> On Sat, Dec 20, 2014 at 11:55 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Sat, 20 Dec 2014 11:14:39 -0800
>> >> From: Doug Evans <xdje42@gmail.com>
>> >> Cc: "gdb-patches@sourceware.org" <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. :-)]
next prev parent reply other threads:[~2014-12-21 18:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-01 8:23 [RFC] " Doug Evans
2014-12-03 0:50 ` Doug Evans
2014-12-20 7:57 ` [PATCH] " Doug Evans
2014-12-20 8:29 ` Doug Evans
2014-12-20 10:43 ` Eli Zaretskii
2014-12-20 19:14 ` Doug Evans
2014-12-20 19:55 ` Eli Zaretskii
2014-12-20 21:04 ` Doug Evans
2014-12-21 3:34 ` Eli Zaretskii
2014-12-21 18:51 ` Doug Evans [this message]
2014-12-21 21:01 ` Joel Brobecker
2014-12-22 2:04 ` Doug Evans
2014-12-22 12:48 ` Joel Brobecker
2015-01-11 19:11 ` Doug Evans
2014-12-03 2:46 ` [RFC] " Joel Brobecker
2014-12-04 16:38 ` Pedro Alves
2014-12-04 19:17 ` Doug Evans
2014-12-04 19:16 ` Jan Kratochvil
2014-12-04 19:24 ` Doug Evans
2014-12-04 19:28 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAP9bCMRNnQsMB5i962mzT_-H_s+in09A7rZiC6KkQ2NfFzJJjg@mail.gmail.com \
--to=xdje42@gmail.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox