[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 18:26:42 UTC 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