Re: first bisection step takes quite a while

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 21, 2025 at 9:24 PM Christian Couder
<christian.couder@xxxxxxxxx> wrote:
>
> On Fri, Feb 21, 2025 at 6:47 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:

> > >>  * The "this is good enough" logic currently allows us to be within
> > >>    0.1% of the real halfway point.  Until the candidate set becomes
> > >>    small enough, we could loosen the criteria to allow larger, say
> > >>    3%, slack.  This code is written but not enabled (with "0 &&").
> >
> > The above follows the same reasoning why we chose "division by 1024"
> > in the first place.  The illustration patch postulates that we could
> > be way more aggressive than 0.1% while the set is large by dividing
> > 64, without wanting to loosen the criteria near the end of the
> > bisection session when the remaining set is reasonably small like
> > 1000 commits.  So we cannot rely on integer division truncating.
>
> The code you posted above uses 10000 as the threshold, not 1000:
>
> 10000 < nr && abs(diff) < nr / 64) || abs(diff) < nr / 1024)

Also if "division by 1024" means within 0.1% of the real halfway
point, then division by 64 means 0.1 * 1024 / 64 = 1.6 % not 3%.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux