Re: Question about the ahead-behind computation and status

2017-12-15 Thread Derrick Stolee
On 12/15/2017 1:30 PM, Junio C Hamano wrote: Derrick Stolee writes: The biggest reason for the 20 seconds is not just the number of commits in the ahead/behind but how many commits are walked (including common to both branches) before paint_down_to_common() breaks its while

Re: Question about the ahead-behind computation and status

2017-12-15 Thread Junio C Hamano
Derrick Stolee writes: > The biggest reason for the 20 seconds is not just the number of > commits in the ahead/behind but how many commits are walked (including > common to both branches) before paint_down_to_common() breaks its > while loop due to queue_has_nonstale(). Hmm,

Re: Question about the ahead-behind computation and status

2017-12-15 Thread Derrick Stolee
On 12/15/2017 10:08 AM, Jeff Hostetler wrote: On 12/15/2017 5:08 AM, Jeff King wrote: On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: [*] Sadly, the local repo was only about 20 days out of date (including the Thanksgiving holidays) Taking 20 seconds to traverse 20

Re: Question about the ahead-behind computation and status

2017-12-15 Thread Jeff Hostetler
On 12/15/2017 5:08 AM, Jeff King wrote: On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: I don't want to jump into the graph algorithm at this time, but was wondering about adding a --no-ahead-behind flag (or something similar or a config setting) that would disable the a/b

Re: Question about the ahead-behind computation and status

2017-12-15 Thread Jeff King
On Thu, Dec 14, 2017 at 04:49:31PM -0500, Jeff Hostetler wrote: > I don't want to jump into the graph algorithm at this time, > but was wondering about adding a --no-ahead-behind flag (or > something similar or a config setting) that would disable > the a/b computation during status. > > For

Question about the ahead-behind computation and status

2017-12-14 Thread Jeff Hostetler
We working with the (enormous) Windows repo, we observed a performance problem in the ahead-behind computation and were considering a few options. We had a local repo with a local branch that was 150K commits behind the upstream branch[*]. There was a ~20 second different in the run times for