[PATCH STABLE] commit: increase perf by avoiding unnecessary filteredrevs check

[Pierre-Yves David]

On 19 nov. 2012, at 23:12, Matt Mackall wrote:

> On Fri, 2012-11-16 at 15:40 -0800, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham at fb.com>
>> # Date 1353109152 28800
>> # Node ID 270338011eff9c88433e9cced0ba4a1c424b3d4a
>> # Parent  adca8ebf288c9ed00166298f3be192747d889b82
>> commit: increase perf by avoiding unnecessary filteredrevs check
> 
> FYI, this is probably at the limit of what I think belongs on stable.
> 
> Every code change to stable introduces some risk of new bugs (aka
> 'instability'). To be worth that risk, each change ought to aim to
> monotonically increase correctness with a bare minimum of change.
> 
> So in general, we don't accept even "obviously harmless" cleanups on
> stable - they just have to wait three months for the next release.
> 
> This particular code is in a bit of a gray area. Fixing a 1% performance
> regression would almost certainly not be accepted here, while a 100%
> regression might be, depending on the importance of the workload.

The key element here is probably that the performance regression is done at the
benefit of no new feature from the user point of view. The filtering is
implemented changelog side but it has zero user inside or outside core.

The safest move here is probably to just drop the wrapping of the `revs` method
in changelog *on the stable branch*. This would get us back to the previous
situation.

-- 
Pierre-Yves