On Mon, Apr 9, 2018 at 9:49 PM, Florian Gamböck <ml@xxxxxxxx> wrote:
> On 2018-04-09 11:26, Stefan Beller wrote:
>> If Gits own completion script would be broken up by subcommand, would that
>> also deliver an improvement in performance?
>
>
> As it is now, the completion script is quite big. On a system with limited
> resources, the initial loading time can be long and the memory footprint is
> big, given that most users will just use a few commands. If you just use the
> "commit" subcommand, the first loading of the two (smaller) scripts will be
> slightly longer the first time (but not as long as with one big script, I
> think), but the footprint will be drastically lower. The whole script is
> 56kB big (without comments), after radically removing everything which is
> not connected to _git_commit, it is only 11kB.
>
> So to answer your question: Yes. My first intuition is, that by splitting
> the completion script and loading the sub-scripts dynamically, it will
> improve in terms of speed and overall memory footprint, at least for the
> average user that does not fire up all possible git commands.
While "most users" might indeed only use a couple of git commands,
they don't use systems so limited in resources where 56k vs. 11k makes
a non-negligible difference. A system, where such a small difference
is significant, must be so thight on resources that the user will most
likely have issues running git anyway.
I don't know how much memory Bash uses to store completion scripts,
and it appears to be using a memory pool or something like our
ALLOC_GROW, making measuring its memory footprint with simple means
unusably inaccurate. Anyway, here are some numbers:
# Baseline, bash does nothing:
$ command time -f %M bash -c ''
2924
# Loading a <10k script:
$ wc -c ./git-sh-setup.sh
9313 ./git-sh-setup.sh
command time -f %M bash -c '. ./git-sh-setup.sh'
3724
# Loading our completion script; the increase in max memory
# footprint is clearly not proportional to the size of the loaded
# script:
$ wc -c ./contrib/completion/git-completion.bash
69413 ./contrib/completion/git-completion.bash
$ command time -f %M bash -c '. ./contrib/completion/git-completion.bash'
4092
# The main bash-completion script, though slightly smaller than ours,
# appears to be requiring much more memory:
$ wc -c /usr/share/bash-completion/bash_completion
67661 /usr/share/bash-completion/bash_completion
$ command time -f %M bash -c './usr/share/bash-completion/bash_completion'
5952
# Loading both the main bash-completion script and our completion
# script, which is where that memory pool/ALLOC_GROW-like thingy really
# kicks in, as there is no real max memory footprint increase:
$ command time -f %M bash -c '. /usr/share/bash-completion/bash_completion
. ./contrib/completion/git-completion.bash'
5964
OTOH, our completion script has a couple of nice properties that we
should keep working:
- A user can simply run '. /path/to/git-completion.bash', and then
completion for git commands will work. Even without
bash-completion package, even in 'bash --norc'.
If we were to split up our completion script, we would also have
to roll our own __git_load_completion() funcion.
- A user building Git from source doesn't have to install the
completion script, it can be sourced from anywhere. And if the
user chooses to install it somewhere, only a single file has to be
copied.
Currently we have completion functions for 55 git commands, which
would mean 56 files to install if the completion script were split
up.
- Sourcing 'git-completion.bash' brings in all the latest and
greatest.
If it were split up, then sourcing it would only update the common
functions, but not the completion functions of individual git
commands. So we would have to take extra steps to delete those
command-specific completion functions upon sourcing the completion
script. However, we should be extra careful to delete only those
completion functions that were source by the completion script,
because users might have defined such functions in their
'~/.bashrc'...
I don't think it's worth it.
