Re: [PATCH] Speedup bash completion loading

From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Oct 5, 2009, 16:58 UTC
Message-ID: <20091005165802.GA24402@tugrik.mns.mnsspb.ru>
In-Reply-To: <20091005152504.GE9261@spearce.org>

On Mon, Oct 05, 2009 at 08:25:04AM -0700, Shawn O. Pearce wrote:

Show 10 quoted lines

> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > I've tracked down that the most time is spent warming up merge_strategy,
> > all_command & porcelain_command caches.
> 
> Nak.
> 
> The problem is, during completion when we modify the value the
> change doesn't persist beyond the current completion invocation.
> Thus there is no value in the cache, so every completion attempt
> which needs the list has to rerun the command to compute it.

Yes, my mistake.

To avoid spawning subshell on $(__git_porcelain_commands) I could come up with "caching" at the upper level, as e.g.

@@ -2107,7 +2111,10 @@ _git ()
                        --help
                        "
                        ;;
-               *)     __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+               *)     __gitcomp "
+                       ${__git_porcelain_commandlist:=$(__git_porcelain_commands)}
+                       $(__git_aliases)
+                       " ;;


but that's ugly and not maintainable since e.g. __git_all_commands() is used in
several places.


The other possibility is to pregenerate all these lists at git build time, but
are we going to do it for things under contrib/ ?


This could have easy solution if bash provided analog of $() to call a function
and obtain either its stdout or return value without spawning subshell, but up
to now I could not find such a construct in bash's man.

I have to go, but I'll try to come up with something practical in several days.


Thanks for spotting it,
Kirill