[PATCH 1 of 2] bdiff: early pruning of common prefix before doing expensive computations

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Nov 24 13:26:42 EST 2016



On 11/17/2016 10:30 PM, Augie Fackler wrote:
> On Thu, Nov 17, 2016 at 08:29:46PM +0100, Mads Kiilerich wrote:
>> On 11/17/2016 07:53 PM, Gregory Szorc wrote:
>>> On Thu, Nov 17, 2016 at 9:16 AM, Mads Kiilerich <mads at kiilerich.com
>>> <mailto:mads at kiilerich.com>> wrote:
>>>
>>>    # HG changeset patch
>>>    # User Mads Kiilerich <madski at unity3d.com <mailto:madski at unity3d.com>>
>>>    # Date 1479321935 -3600
>>>    #      Wed Nov 16 19:45:35 2016 +0100
>>>    # Node ID 7f39bccc1c96bffc83f3c6e774da57ecd38982a7
>>>    # Parent  fe6a3576b863955a6c40ca46bd1d6c8e5384dedf
>>>    bdiff: early pruning of common prefix before doing expensive
>>>    computations
>
> [...]
>
>>>    diff --git a/mercurial/bdiff_module.c b/mercurial/bdiff_module.c
>>>    --- a/mercurial/bdiff_module.c
>>>    +++ b/mercurial/bdiff_module.c
>>>    @@ -61,12 +61,12 @@ nomem:
>>>
>>>     static PyObject *bdiff(PyObject *self, PyObject *args)
>>>
>>>
>>> Implementing this in the Python module means that CFFI/PyPy won't be able
>>> to realize the perf wins :(
>>>
>>> How do you feel about implementing this in bdiff.c?
>>
>> I guess other logic also should move from bdiff_module to bdiff.c? This was
>> just the easy way to hook in before the two sides got split into lines.
>
> If you're willing, I'd be a big fan of this change happening in such a
> way that pypy gets the wins too. What say you?

So, what is the status of this? Should we expect a V2 with the code 
living in bdiff.c?

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list