facebook/sapling
1
1
Fork 0
mirror of https://github.com/facebook/sapling.git synced 2024-10-07 15:27:13 +03:00
Code Issues Projects Releases Wiki Activity

obsolete: fix n^2 marker computation behavior

Browse Source 
Previously, if you ran obsolete.createmarkers with a bunch of markers that did
not have successors (like when you do a prune), it encountered a n^2 computation
behavior because the loop would read the changelog (to get ctx.parents()), then
add a marker, in a loop.  Adding a marker invalidated the computehidden cache,
and reading the changelog recomputed it.

This resulted in pruning 150 commits taking 150+ seconds in a large repo.

The fix is to break the reading part of the loop to be separate from the writing
part.
This commit is contained in:
Durham Goode 2016-02-04 15:38:04 -08:00
parent 0660375798
commit 196a302117
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
mercurial/obsolete.py
View File

@ -1225,6 +1225,7 @@ def createmarkers(repo, relations, flag=0, date=None, metadata=None):
metadata['user'] = repo.ui.username()
tr = repo.transaction('add-obsolescence-marker')
try:
markerargs = []
for rel in relations:
prec = rel[0]
sucs = rel[1]
@ -1243,6 +1244,15 @@ def createmarkers(repo, relations, flag=0, date=None, metadata=None):
npare = tuple(p.node() for p in prec.parents())
if nprec in nsucs:
raise error.Abort("changeset %s cannot obsolete itself" % prec)
# Creating the marker causes the hidden cache to become invalid,
# which causes recomputation when we ask for prec.parents() above.
# Resulting in n^2 behavior. So let's prepare all of the args
# first, then create the markers.
markerargs.append((nprec, nsucs, npare, localmetadata))
for args in markerargs:
nprec, nsucs, npare, localmetadata = args
repo.obsstore.create(tr, nprec, nsucs, flag, parents=npare,
date=date, metadata=localmetadata)
repo.filteredrevcache.clear()