[Bash-completion-devel] After adding bash-completion to .bashrc loading prompt is slow

[Ville Skyttä]

On 04/04/2011 02:02 PM, Guillaume Rousse wrote:
> Le 03/04/2011 14:33, David Paleino a écrit :
>> It's a Celeron 1,73GHz, bash-completion from git, 242 files in
>> bash_completion.d, Debian sid.
>>
>>> I tried with the slowest box I have easily access to (which has
>>> bash-completion 1.2 with 52 files in /etc/bash_completion.d,
> The issue seems clearly comes the number of individual files to be
> sourced in bash_completion.d (52 vs 242).

That does have an effect, but I don't think it's that clear cut that
it's the number of files that makes the difference.  In addition to
that, there is also the number of have() calls etc (but those tend to go
hand in hand with the number of files with the current setup).  See
below for some numbers.

> I guess Ville only has
> relevant files there, while David (and probably Martin also) has all
> available ones.

For the other box (my desktop) I have everything from git plus a handful
of others, total 195 at the moment.  But that's the one with an SSD
disk.  Load time after dropping caches etc with those 195 files there
looks like:

real	0m0.681s
user	0m0.433s
sys	0m0.106s

...and after combining all those to a single file:

real	0m0.558s
user	0m0.375s
sys	0m0.081s

Corresponding numbers from the other slower box I mentioned, with 52
split files:

real	0m1.468s
user	0m0.187s
sys	0m0.040s

...and after combining all those to just one:

real	0m1.122s
user	0m0.180s
sys	0m0.034s

...and if I additionally comment out the "PATH=... type ..." line from
have() in bash_completion so that it always sets have=yes:

real	0m0.652s
user	0m0.161s
sys	0m0.020s

That's quite an improvement.  Now if I put back the split 52 files but
leave the have() hack in place:

real	0m0.834s
user	0m0.168s
sys	0m0.029s

So it seems that we spend a lot of time in have().  And it's pretty much
completely unnecessary on this box because it has only relevant
completion files installed in place :P.  I suppose distro packagers
could consider doing something about this at least until we get it
sorted out upstream, at least I plan to take a look at it in the Fedora
and EPEL packages.