This is the mail archive of the
mailing list for the GDB project.
Re: Adding an early exit option to readline completion routines
- From: Sterling Augustine <saugustine at google dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>, gdb at sourceware dot org
- Date: Wed, 8 Jun 2011 09:42:35 -0700
- Subject: Re: Adding an early exit option to readline completion routines
- References: <BANLkTinULEBk+QfYNVK8-E4CeqFqDmURo1--4-rthTUK2Xuw1A@mail.gmail.com> <20110608133222.GA5168@host1.jankratochvil.net>
<Adding gdb list>
[This is a discussion of tab-completion performance.]
On Wed, Jun 8, 2011 at 6:32 AM, Jan Kratochvil
> I find this is a perfect topic for gdb@ or gdb-patches@, may I forward
> your+mine mails to gdb@?
> I find the primary question which problem do we solve.
> FSF gdb 7.1 was pre-physname, before the following patch was accepted:
> ? ? ? ?commit 42284fdf9d8cdb20c8e833bdbdb2b56977fea525
> ? ? ? ?Author: Keith Seitz <firstname.lastname@example.org>
> ? ? ? ?Date: ? Tue Mar 9 18:09:04 2010 +0000
> ? ? ? ? ? ?dwarf2_physname patchset:
> FSF gdb 7.2 is already post-physname, with the physname patch included.
> Since physname there were also some functionality bugs with the completion
> which I fixed post-7.2.
> Thefore I would find for comparison relevant:
> FSF gdb-7.1 - pre-physname GDB (with correct functionality of the completion)
> FSF gdb-7.3 - post-physname GDB with correct(ed) functionality of the completion
> (FSF gdb-7.3 is not released, therefore FSF gdb-7.2.90.* or gdb-7.3.50.*)
> Do you find gdb-7.1 also slow? ?It was not superfast but I believe it was fast
GDB 7.1 finds roughly 2/3 as many matches as TOT, but is about 3x
faster. That is still a little too slow for my preference because it
still takes about six seconds, but once I figure out why this process
isn't interrupt-able, that would be adequate.
To somewhat complicate matters--Profiling shows that over half-the
time spent in tab-completion is spent handling multibyte strings.
Simply configuring with "--enable-multibyte=no" halves the time needed
for my test cases on both TOT and 7.1. If you don't have any multibyte
symbol names or identifiers, then this time is completely wasted. If
you do, then it is indispensable.
> If you find gdb-7.3 too slow then I think we are discussing the problem
> described in the last paragraph of:
> ? ? ? ?[patch][+7.3] Fix physname completion regression
> ? ? ? ?http://sourceware.org/ml/gdb-patches/2011-04/msg00140.html
> I talk only about this latter problem below.
> For the gdb-7.3 performance regression I do not find disabling the 100000+
> matches as needed. ?GDB partial symtabs (or .gdb_index) already contain all
> the 100000+ entries available immediately for the completion. ?Just since
> physname they do not contain the fully qualified C++ parameters.
> gdb-7.1 psymtab: func(int,long)
> gdb-7.1 ?symtab: func(int,long)
> gdb-7.3 psymtab: func
> gdb-7.3 ?symtab: func(int,long)
> gdb-7.3 currently expands all the CUs (Compilation Units) for every completion
> candidate (those 100000+) to find out the parameters (`(int,long)') - this is
> very very slow.
> There could be a GDB modification that if we find out we would return more
> than rl_completion_query_items entries GDB will return just the bare names
> `func' as in such case people are probably not interested in the detailed
> parameter types yet anyway, they can even complete upon the function name to
> reduce the completion set and get later the full parameters qualification for
> the reduced set of candidates.
This does seem to be the right approach.