D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.
martinvonz abandoned this revision.


  I'll abandon this in favor of D7492 

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#109543 , @marmoute 
wrote:
  
  > I am working on a non-experimental series that get things more contained in 
repo/changectx to robustness. It also contains tests making sure we do not 
regress. I think we could so something really robust, efficient and 
transparent, but having this and that filtered changelog level, with lazyer 
filtering computation. However I think I dig the rabbit out enough for now. 
Eventually I think we could get O(1) filtering too removing the need for all 
this.
  > Sorry for the delay. I need a bit more (actual coding) time to clean this 
up and submit it.
  
  That's fine. Thanks for the update. I'm glad you had not forgotten about it.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  I am working on a non-experimental series that get things more contained in 
repo/changectx to robustness. It also contains tests making sure we do not 
regress. I think we could so something really robust, efficient and 
transparent, but having this and that filtered changelog level, with lazyer 
filtering computation. However I think I dig the rabbit out enough for now. 
Eventually I think we could get O(1) filtering too removing the need for all 
this.
  
  Sorry for the delay. I need a bit more (actual coding) time to clean this up 
and submit it.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  In D7144#108574 , @martinvonz 
wrote:
  
  > In D7144#108444 , @marmoute 
wrote:
  >
  >> I took more time to look at your series and at the bigger picture. My 
general position is still that passing the wrong filter level to high level 
function is hacking and will be a significant source of bugs.
  >
  > I agree that it's a hack.
  >
  >> For example, `hg status` taks a "PATTERN" argument, that pattern can be 
fileset, that fileset can contains revset. PAssing the wrong filtering will 
result in wrongdoing of that revset.
  >> However it might be a good idea to do this hack if:
  >>
  >> - the performance gain is significant,
  >> - the hack is temporary,
  >> - there is no reasonable alternative available short terms.
  >>
  >> I took some time to poke at the issues, and I managed to get all 4 
commands listed in this series with a first throw of abotu 12 changesets. The 
idea is to recognise pattern that will not be filtered and to have lower level 
logic skip around the filtering in this case. So the higher level logic is 
still filtered with the right semantic. One can have a look at the very first 
throw here:  
https://dev.heptapod.net/octobus/mercurial-devel/commits/topic/default/filter-trigger
  >
  > I did something similar (but much smaller in scope) a long time ago: 
https://www.mercurial-scm.org/repo/hg/rev/a9b61dbdb827. That hack has since 
become ineffective, and I think some of your commits aim at restoring its 
effect. I felt that that approach was also fragile since quite subtle code 
changes can make it stop working (as has already happened with my original 
hack). So I'm not convinced that is the right approach either, but I'm fine 
with taking that series instead if you clean it up (I do see the risk of bugs 
with my series).
  
  I think a consolidated approach will work reasonably well in most simpe case. 
However, yes, the approach is "fragile" since any other code directly touching 
`repo.changelog` would trigger the filtering. (We could probably improve that 
too).
  
  Since I am about to add a filtered repository to the benchmarks, we should be 
able to detect regression here. That's not ideal… but eventually we will also 
speed up the filtering itself.
  
  > Relatedly, I would really like to have the filtering applied only when 
walking towards children in the changelog (this is something that Durham has 
mentioned before),
  
  I think a generalisation of my current approach is close to that. If you walk 
parent from a revision that you know to exists, you don't need to check 
filtering.
  
  > so no filtering happens even if you do `hg status -r ` 
or similar. But that's a much larger change, of course.
  >
  >> It is getting late so I will stop here for tonight. However, the prototype 
looks promissing enough. I can probably have a clean/consolidate version by the 
end of the week.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#108444 , @marmoute 
wrote:
  
  > I took more time to look at your series and at the bigger picture. My 
general position is still that passing the wrong filter level to high level 
function is hacking and will be a significant source of bugs.
  
  I agree that it's a hack.
  
  > For example, `hg status` taks a "PATTERN" argument, that pattern can be 
fileset, that fileset can contains revset. PAssing the wrong filtering will 
result in wrongdoing of that revset.
  > However it might be a good idea to do this hack if:
  >
  > - the performance gain is significant,
  > - the hack is temporary,
  > - there is no reasonable alternative available short terms.
  >
  > I took some time to poke at the issues, and I managed to get all 4 commands 
listed in this series with a first throw of abotu 12 changesets. The idea is to 
recognise pattern that will not be filtered and to have lower level logic skip 
around the filtering in this case. So the higher level logic is still filtered 
with the right semantic. One can have a look at the very first throw here:  
https://dev.heptapod.net/octobus/mercurial-devel/commits/topic/default/filter-trigger
  
  I did something similar (but much smaller in scope) a long time ago: 
https://www.mercurial-scm.org/repo/hg/rev/a9b61dbdb827. That hack has since 
become ineffective, and I think some of your commits aim at restoring its 
effect. I felt that that approach was also fragile since quite subtle code 
changes can make it stop working (as has already happened with my original 
hack). So I'm not convinced that is the right approach either, but I'm fine 
with taking that series instead if you clean it up (I do see the risk of bugs 
with my series).
  
  Relatedly, I would really like to have the filtering applied only when 
walking towards children in the changelog (this is something that Durham has 
mentioned before), so no filtering happens even if you do `hg status -r ` or similar. But that's a much larger change, of course.
  
  > It is getting late so I will stop here for tonight. However, the prototype 
looks promissing enough. I can probably have a clean/consolidate version by the 
end of the week.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  I took more time to look at your series and at the bigger picture. My general 
position is still that passing the wrong filter level to high level function is 
hacking and will be a significant source of bugs.
  
  For example, `hg status` taks a "PATTERN" argument, that pattern can be 
fileset, that fileset can contains revset. PAssing the wrong filtering will 
result in wrongdoing of that revset.
  
  However it might be a good idea to do this hack if:
  
  - the performance gain is significant,
  - the hack is temporary,
  - there is no reasonable alternative available short terms.
  
  I took some time to poke at the issues, and I managed to get all 4 commands 
listed in this series with a first throw of abotu 12 changesets. The idea is to 
recognise pattern that will not be filtered and to have lower level logic skip 
around the filtering in this case. So the higher level logic is still filtered 
with the right semantic. One can have a look at the very first throw here:  
https://dev.heptapod.net/octobus/mercurial-devel/commits/topic/default/filter-trigger
  
  It is getting late so I will stop here for tonight. However, the prototype 
looks promissing enough. I can probably have a clean/consolidate version by the 
end of the week.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers, durin42
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.
martinvonz marked an inline comment as done.


  I've extracted a function for deciding whether to use an unfiltered repo, so 
hopefully this can get queued now.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz edited the summary of this revision.
martinvonz updated this revision to Diff 18044.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D7144?vs=17367&id=18044

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

AFFECTED FILES
  mercurial/commands.py

CHANGE DETAILS

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -163,6 +163,20 @@
 subrepoopts = cmdutil.subrepoopts
 debugrevlogopts = cmdutil.debugrevlogopts
 
+
+def _maybeunfilteredrepo(repo, commandname, args, kwargs):
+"""decides if we can optimize by using an unfiltered repo
+
+Extracted to a function so extensions can override it.
+"""
+use_unfiltered = False
+if commandname == b'status':
+if not kwargs.get(b'rev') and not kwargs.get(b'change'):
+use_unfiltered = True
+
+return repo.unfiltered() if use_unfiltered else repo
+
+
 # Commands start here, listed alphabetically
 
 
@@ -6790,6 +6804,8 @@
 else:
 terse = ui.config(b'commands', b'status.terse')
 
+repo = _maybeunfilteredrepo(repo, b'status', pats, opts)
+
 if revs and change:
 msg = _(b'cannot specify --rev and --change at the same time')
 raise error.Abort(msg)



To: martinvonz, #hg-reviewers
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#105248 , @mharbison72 
wrote:
  
  > The comment about maybe affecting extensions made me think of df463ca0adef 
.  
I never figured out what the issue was.
  
  I suspect that's because largefiles creates a repo subclass and that subclass 
does not have the `__getattr__` and `__setattr__` overrides that `repoview` 
does, so setting `lfstatus`or `_largefilesenabled` on that subclass won't 
propagate it to the parent.
  
  In D7144#105352 , @marmoute 
wrote:
  
  > In D7144#105048 , @martinvonz 
wrote:
  >
  >> In D7144#105039 , @marmoute 
wrote:
  >>
  >>>   I have a couple of questions:
  >>>
  >>> […]
  >>>
  >>> - This could cause issue to extensions, can we abtract the unfiltering 
though a function so that extension can rewrap it ?
  >>
  >> To make sure I address it properly, what's the issue(s) you're thinking of?
  >
  > Imagine you are an extension writer adding extra information on status (eg: 
tell the user if his stack is behind and he needs to rebase). If you get an 
unfiltered repository, any operation you run (eg: a revset to check the graph, 
will go horribly wrong). So we need need at minimum an easy way to disable the 
unfiltering if an extension needs to do it.
  >
  > In D7144#105066 , @martinvonz 
wrote:
  >
  >> In D7144#105065 , @marmoute 
wrote:
  >>
  >>> Another question is " Why are we loading the changelog if we don't need 
it ?". If the code were not accessing the changelog, we could not pay the 
filtering code (and save other parsing cost).
  >>
  >> We load the changelog when we do `repo['.']`. I had added a hack 
(https://www.mercurial-scm.org/repo/hg/file/4565a0afc289/mercurial/localrepo.py#l1539)
 to try to avoid that, but it was no longer effective. I think using the 
unfiltered repo is a better solution anyway.
  >
  > If the performance gain are clear, using an unfiltered repository seems 
like a reasonable gain/risk move. However I would prefer this to remain 
temporary. Keeping the repository filtering aligned to the current semantic is 
important to avoid surprise and obscure bug in the future. We need an overall 
effort to reduce the filtering impact anyway (independantly from this series).
  > In the case here, I wonder if we have and easy way to prevent the filtering 
computation kick in, as it is clearly unnecessary.
  >
  > - can you share a profile of what takes time with the filtering version
  > - Do you know which part is triggering the filtering ?
  
  I'll get back to you about the other things later, but I think the following 
profile answers these last questions:
  
| 100.0%  0.19s  dispatch.py:_callcatchline 36:  dispatch.run()
| 100.0%  0.19s  scmutil.py: callcatch line 433:  return 
scmutil.callcatch(ui...
| 100.0%  0.19s  dispatch.py:_runcatchfunc line 177:  return func()
| 100.0%  0.19s  hg.py:  repositoryline 414:  return 
_dispatch(req)
 \ 52.6%  0.10s  localrepo.py:   statusline 6831:  
opts.get(b'subrepos'),
   \ 31.6%  0.06s  localrepo.py:   __getitem__ line 3248:  return 
self[node1].status(
 | 31.6%  0.06s  repoview.py:changelog line 1547:  rev = 
self.changelog.rev(ch...
 | 31.6%  0.06s  repoview.py:filterrevsline 278:  revs = 
filterrevs(unfi, sel...
 | 31.6%  0.06s  repoview.py:computehidden line 217:  
repo.filteredrevcache[filte...
   \ 15.8%  0.03s  repoview.py:hideablerevsline 87:  hidden = 
hideablerevs(repo)
 | 15.8%  0.03s  obsolete.py:getrevs   line 39:  obsoletes = 
obsolete.getrev...
 | 15.8%  0.03s  obscache.py:  line 905:  
repo.obsstore.caches[name] ...
 | 15.8%  0.03s  obscache.py:_computeobsoletesetline  469:  
wrapped = lambda repo: _com...
 | 10.5%  0.02s  phases.py:  getrevset line 434:  notpublic = 
repo._phasecach...
   \  5.3%  0.01s  scmutil.py: __get__ line 106:  return 
super(_basefilecache...
 |  5.3%  0.01s  localrepo.py:   _phasecacheline 1636:  
entry.obj = self.func(obj)
 |  5.3%  0.01s  phases.py:  __init__line 1432:  return 
phases.phasecache(se...
 |  5.3%  0.01s  phases.py:  _readrootsline 235:  
self.phaseroots, self.dirty...
   \  5.3%  0.01s  phases.py:  loadphaserevsline 243:  
self.loadphaserevs(repo)  #...
 |  5.3%  0.01s  phases.py:  _getphaserevsnativeline  
325:  res = self._getphaserevsnat...
 |  5.3%  0.01s  changelog.py:   rev   line 301:  
pycompat.maplist(repo.chang...
   \ 10

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  
  
  In D7144#105048 , @martinvonz 
wrote:
  
  > In D7144#105039 , @marmoute 
wrote:
  >
  >>   I have a couple of questions:
  >>
  >> […]
  >>
  >> - This could cause issue to extensions, can we abtract the unfiltering 
though a function so that extension can rewrap it ?
  >
  > To make sure I address it properly, what's the issue(s) you're thinking of?
  
  Imagine you are an extension writer adding extra information on status (eg: 
tell the user if his stack is behind and he needs to rebase). If you get an 
unfiltered repository, any operation you run (eg: a revset to check the graph, 
will go horribly wrong). So we need need at minimum an easy way to disable the 
unfiltering if an extension needs to do it.
  
  In D7144#105066 , @martinvonz 
wrote:
  
  > In D7144#105065 , @marmoute 
wrote:
  >
  >> Another question is " Why are we loading the changelog if we don't need it 
?". If the code were not accessing the changelog, we could not pay the 
filtering code (and save other parsing cost).
  >
  > We load the changelog when we do `repo['.']`. I had added a hack 
(https://www.mercurial-scm.org/repo/hg/file/4565a0afc289/mercurial/localrepo.py#l1539)
 to try to avoid that, but it was no longer effective. I think using the 
unfiltered repo is a better solution anyway.
  
  If the performance gain are clear, using an unfiltered repository seems like 
a reasonable gain/risk move. However I would prefer this to remain temporary. 
Keeping the repository filtering aligned to the current semantic is important 
to avoid surprise and obscure bug in the future. We need an overall effort to 
reduce the filtering impact anyway (independantly from this series).
  
  In the case here, I wonder if we have and easy way to prevent the filtering 
computation kick in, as it is clearly unnecessary.
  
  - can you share a profile of what takes time with the filtering version
  - Do you know which part is triggering the filtering ?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[mharbison72 (Matt Harbison)]

mharbison72 added a comment.


  The comment about maybe affecting extensions made me think of df463ca0adef 
.  
I never figured out what the issue was.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: mharbison72, pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#105048 , @martinvonz 
wrote:
  
  > In D7144#105039 , @marmoute 
wrote:
  >
  >> I have a couple of questions:
  >>
  >> - Can we get performance number with about without this patch ? (to gauge 
the relative gain)
  >
  > Will get that later (I have ~2 weeks before the end of freeze anyway :))
  >
  >> - This could cause issue to extensions, can we abtract the unfiltering 
though a function so that extension can rewrap it ?
  >
  > To make sure I address it properly, what's the issue(s) you're thinking of?
  
  @marmoute, could you explain what the issue is? And what function would I 
extract to help solve it?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#105065 , @marmoute 
wrote:
  
  > Another question is " Why are we loading the changelog if we don't need it 
?". If the code were not accessing the changelog, we could not pay the 
filtering code (and save other parsing cost).
  
  We load the changelog when we do `repo['.']`. I had added a hack 
(https://www.mercurial-scm.org/repo/hg/file/4565a0afc289/mercurial/localrepo.py#l1539)
 to try to avoid that, but it was no longer effective. I think using the 
unfiltered repo is a better solution anyway.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  Another question is " Why are we loading the changelog if we don't need it 
?". If the code were not accessing the changelog, we could not pay the 
filtering code (and save other parsing cost).

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added inline comments.

INLINE COMMENTS

> commands.py:6774
> +if not revs and not change:
> +# Avoid loading obsmarkers if we're accessing only the working copy
> +# parent (which will never be hidden).

Are you using the evolve extension. If so you should -already- not be loading 
obsmarkers (but there are other filtering associated cost). If you are using 
evolve and actually loading obsmarkers for this operation, we have a regression 
somewhere to fix first.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  In D7144#105039 , @marmoute 
wrote:
  
  > I have a couple of questions:
  >
  > - Can we get performance number with about without this patch ? (to gauge 
the relative gain)
  
  Will get that later (I have ~2 weeks before the end of freeze anyway :))
  
  > - This could cause issue to extensions, can we abtract the unfiltering 
though a function so that extension can rewrap it ?
  
  To make sure I address it properly, what's the issue(s) you're thinking of?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[pulkit (Pulkit Goyal)]

pulkit added a comment.


  I am +1 on this idea. I see @marmoute has some concerns around extensions 
wrapping, once they are addressed, I will push it once the freeze ends.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: pulkit, marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[marmoute (Pierre-Yves David)]

marmoute added a comment.


  I have a couple of questions:
  
  - Can we get performance number with about without this patch ? (to gauge the 
relative gain)
  - This could cause issue to extensions, can we abtract the unfiltering though 
a function so that extension can rewrap it ?

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: marmoute, mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz updated this revision to Diff 17367.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST UPDATE
  https://phab.mercurial-scm.org/D7144?vs=17356&id=17367

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

AFFECTED FILES
  mercurial/commands.py

CHANGE DETAILS

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -6770,6 +6770,11 @@
 else:
 terse = ui.config(b'commands', b'status.terse')
 
+if not revs and not change:
+# Avoid loading obsmarkers if we're accessing only the working copy
+# parent (which will never be hidden).
+repo = repo.unfiltered()
+
 if revs and change:
 msg = _(b'cannot specify --rev and --change at the same time')
 raise error.Abort(msg)



To: martinvonz, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz added a comment.


  To reviewers: I only care about this patch (and its parent is needed for this 
to pass tests). Feel free to drop any other patches you don't like.

REPOSITORY
  rHG Mercurial

CHANGES SINCE LAST ACTION
  https://phab.mercurial-scm.org/D7144/new/

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

To: martinvonz, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

D7144: status: use unfiltered repo if we're getting status of working copy

[martinvonz (Martin von Zweigbergk)]

martinvonz created this revision.
Herald added a subscriber: mercurial-devel.
Herald added a reviewer: hg-reviewers.

REVISION SUMMARY
  Loading the filtered repo can be slow if there are many obsmarkers and
  it's not needed in the plain `hg status` case. This saves about 60ms
  in my hg repo and about 200ms in a repo I use at work (where we have
  an extension that hooks into repoview.pinnedrevs()).

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D7144

AFFECTED FILES
  mercurial/commands.py

CHANGE DETAILS

diff --git a/mercurial/commands.py b/mercurial/commands.py
--- a/mercurial/commands.py
+++ b/mercurial/commands.py
@@ -6767,6 +6767,11 @@
 else:
 terse = ui.config(b'commands', b'status.terse')
 
+if not revs and not change:
+# Avoid loading obsmarkers if we're accessing only the working copy
+# parent (which will never be hidden).
+repo = repo.unfiltered()
+
 if revs and change:
 msg = _(b'cannot specify --rev and --change at the same time')
 raise error.Abort(msg)



To: martinvonz, #hg-reviewers
Cc: mercurial-devel
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel