Skip to content
Snippets Groups Projects
  • Mads Kiilerich's avatar
    7d63398fbfd1
    branchmap: use revbranchcache when updating branch map · 7d63398fbfd1
    Mads Kiilerich authored
    The revbranchcache is read on demand before it will be used for updating the
    branch map. It is written back when the branchmap is written and it will thus
    use the same locking as branchmap. The revbranchcache instance is short-lived;
    it is only stored in the branchmap from .update() is invoked and until .write()
    is invoked. Branchmap already assume that the repo is locked in that case.
    
    The use of revbranchcache for branch map updates will make sure that the
    revbranchcache "always" is kept up-to-date.
    
    The perfbranchmap benchmark is somewhat bogus, especially when we can see that
    the caching makes a significant difference between the realistic case of a
    first run and the rare case of rerunning it with a full cache. Here are some
    'base' numbers on mozilla-central:
    Before:
    ! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3)
    After - initial, cache is empty:
    ! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3)
    After - cache is full:
    ! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4)
    
    The overhead when running with empty cache comes from checking, missing and
    updating it every time.
    
    Most of the performance improvement comes from not having to extract the branch
    info from the changelog. The last doubling of performance comes from no longer
    having to convert all branch names to local encoding but reuse the few already
    converted branch names.
    
    On the hg repo:
    Before:
    ! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
    After:
    ! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)
    7d63398fbfd1
    History
    branchmap: use revbranchcache when updating branch map
    Mads Kiilerich authored
    The revbranchcache is read on demand before it will be used for updating the
    branch map. It is written back when the branchmap is written and it will thus
    use the same locking as branchmap. The revbranchcache instance is short-lived;
    it is only stored in the branchmap from .update() is invoked and until .write()
    is invoked. Branchmap already assume that the repo is locked in that case.
    
    The use of revbranchcache for branch map updates will make sure that the
    revbranchcache "always" is kept up-to-date.
    
    The perfbranchmap benchmark is somewhat bogus, especially when we can see that
    the caching makes a significant difference between the realistic case of a
    first run and the rare case of rerunning it with a full cache. Here are some
    'base' numbers on mozilla-central:
    Before:
    ! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3)
    After - initial, cache is empty:
    ! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3)
    After - cache is full:
    ! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4)
    
    The overhead when running with empty cache comes from checking, missing and
    updating it every time.
    
    Most of the performance improvement comes from not having to extract the branch
    info from the changelog. The last doubling of performance comes from no longer
    having to convert all branch names to local encoding but reuse the few already
    converted branch names.
    
    On the hg repo:
    Before:
    ! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
    After:
    ! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)