[MERGE/RFC] Shortcut 'iter_references' when we can't have references

[Ian Clatworthy]

John Arbash Meinel wrote:
> In playing around with merging, I found that the "WT.iter_references()"
> call was showing up somewhat heavily in the time for doing a merge.

I found the same thing when profiling branch on large projects.
In the case of branch though, IIRC the slow iter_references call was
being done in bzrdir.sprout() and the method was on DirStateRevisionTree,
not workingtree_4.

> Anyway, we don't actually need to be doing any of this checking on trees
> that don't support references, which is what this patch does:
> 
> === modified file 'bzrlib/workingtree_4.py'
> --- bzrlib/workingtree_4.py     2008-06-06 16:40:46 +0000
> +++ bzrlib/workingtree_4.py     2008-06-18 15:46:49 +0000
> @@ -528,6 +528,10 @@
> ~         return iter(result)
> 
> ~     def iter_references(self):
> +        if not self._repo_supports_tree_reference:
> +            # We can't have references in this type of tree, so the
> check here

> Thoughts? It seems a shame to penalize (heavily) our normal code because
> we might be supporting references in some formats (that aren't even
> considered production worthy yet.)

That was my thinking too. I'm not close enough to the subtree-related
code to know how safe making this change is, but it does seem that
we're paying a general price for a feature only in specific formats.
If we are able to safely shortcut iter_references, can I request that
your patch be extended to do this in all iter_references implementations?

Ian C.