[Bash-completion-devel] Bug#764800: spurious function in bash-completion causes >30% performance degradation (and is bug'ed)

Ville Skyttä ville.skytta at iki.fi
Tue Oct 14 06:17:13 UTC 2014


On Mon, Oct 13, 2014 at 11:25 PM, Linda A. Walsh <bash at tlinx.org> wrote:
> Ville Skyttä wrote:
>>
>> See comments in bash_completion next to the definition of the
>> function. Due to its deprecated status it is not likely to be changed
>> any more, especially in ways that would change its behavior (e.g. the
>> "type -P" case).
>>
>> The function is not used by bash-completion itself at all,
>
> ---
>         ??? It takes up 30% of the initialization time.

It certainly does not for me.

> How does it take up 1/3rd of the init time if it isn't being
> used?

It doesn't get called a single time in my setup. Note that I'm saying
it is not used *by bash-completion itself* at all, meaning stuff we
ship. "git grep -wF have" in the source tree shows it very clearly.
Why it is being used so much for you I can only guess; maybe you have
many of 3rd party completions installed in the compat completions.d
dir from which stuff is loaded at init time instead of dynamically
that use it. But as I already said, that's something that should be
taken care of in those 3rd party completions. Even if they aren't
loaded dynamically but installed in the backwards compatibility
completions.d dir there's little reason for many of them to use have()
or "type" in the first place -- usually 3rd party completions are
installed at the same time as the commands they complete so they can
just assume the command's presence.

> As for -P  -- that makes it do what it is designed to do. As it
> is, it tests for the presence programs based on function and alias
> definitions. It's supposed to check for the presence of the programs
> in the PATH -- not functions and aliases.

What makes you so certain of what it is designed to do? Sure, checking
for programs is what it's (well, _have() is) documented to do in the
comments, but IIRC the implementation has been like it is for ages and
I can see it being useful for checking aliases and functions as well,
not only programs. When modern bash loads a completion for a command
dynamically, it calls the loader function no matter if the command is
a function or an alias or an executable (or even if it exists or not).
In that sense it doesn't hurt for have() to continue to behave
accordingly.



More information about the Bash-completion-devel mailing list