Re: commit-graph is cool (overcoming add_missing_tags() perf issues)

[Derrick Stolee <stolee@gmail.com>]

On 10/17/2018 2:00 PM, Elijah Newren wrote:
> Hi,
>
> Just wanted to give a shout-out for the commit-graph work and how
> impressive it is.  I had an internal report from a user that git
> pushes containing only one new tiny commit were taking over a minute
> (in a moderate size repo with good network connectivity). After
> digging for a while, I noticed three unusual things about the repo[1]:
>    * he had push.followTags set to true
>    * upstream repo had about 20k tags (despite only 55k commits)
>    * his repo had an additional 2.5k tags, but none of these were in
>      the history of the branches he was pushing and thus would not be
>      included in any pushes.
>
> Digging in, almost all the time was CPU-bound and spent in
> add_missing_tags()[2].  If I'm reading the code correctly, it appears
> that function loops over each tag, calling in_merge_bases_many() once
> per tag.  Thus, for his case, we were potentially walking all of
> history of the main branch 2.5k times.  That seemed rather suboptimal.

Elijah,

Do you still have this repo around? Could you by chance test the 
performance with the new algorithm for add_missing_tags() in [1]? 
Specifically, please test it without a commit-graph file, since your 
data shape already makes use of generation numbers pretty well.

Thanks,
-Stolee

[1] https://public-inbox.org/git/pull.60.git.gitgitgadget@gmail.com/T/#t