Skip to content
Snippets Groups Projects
  • Mads Kiilerich's avatar
    38ed5488
    bdiff: adjust criteria for getting optimal longest match in the A side middle · 38ed5488
    Mads Kiilerich authored
    We prefer matches closer to the middle to balance recursion, as introduced in
    f1ca249696ed.
    
    For ranges with uneven length, matches starting exactly in the middle should
    have preference. That will be optimal for matches of length 1. We will thus
    accept equality in the half check.
    
    For ranges with even length, half was ceil'ed when calculated but we got the
    preference for low matches from the 'less than half' check. To get the same
    result as before when we also accept equality, floor it. Without that,
    test-annotate.t would show some different (still correct but less optimal)
    results.
    
    This will change the heuristics. Tests shows a slightly different output - and
    sometimes slightly smaller bundles.
    
    The bundle size for 4.0 (hg bundle --base null -r 4.0 x.hg) happens to go from
    22804885 to 22803824 bytes - an 0.005% reduction.
    38ed5488
    History
    bdiff: adjust criteria for getting optimal longest match in the A side middle
    Mads Kiilerich authored
    We prefer matches closer to the middle to balance recursion, as introduced in
    f1ca249696ed.
    
    For ranges with uneven length, matches starting exactly in the middle should
    have preference. That will be optimal for matches of length 1. We will thus
    accept equality in the half check.
    
    For ranges with even length, half was ceil'ed when calculated but we got the
    preference for low matches from the 'less than half' check. To get the same
    result as before when we also accept equality, floor it. Without that,
    test-annotate.t would show some different (still correct but less optimal)
    results.
    
    This will change the heuristics. Tests shows a slightly different output - and
    sometimes slightly smaller bundles.
    
    The bundle size for 4.0 (hg bundle --base null -r 4.0 x.hg) happens to go from
    22804885 to 22803824 bytes - an 0.005% reduction.