This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] symbol lookup cache


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. :-)]


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]