Re: RFC: New diff-delta.c implementation

From: Geert Bosch <bosch@adacore.com>
Date: Apr 22, 2006, 17:28 UTC
Message-ID: <EB4042E4-D74E-4346-A9CA-50E9CB33F18C@adacore.com>
In-Reply-To: <7v3bg5k0ev.fsf@assigned-by-dhcp.cox.net>

On Apr 22, 2006, at 13:03, Junio C Hamano wrote:

Show 13 quoted lines

>> What is the exact role of the max_size parameter that
>> is passed to diff_delta? I took it to mean return 0 if
>> the size of the delta would be bigger than max_size and
>> max_size is nonzero.
>
> No, that is a _strong_ hint to tell diff_delta to quit
> early without wasting cycles if the result exceeds the
> given size, either because we already have a delta smaller
> than that, or because we expect to get an undeltified
> representation compressed down to that size.  So if
> your algorithm cannot notice early stage of the processing
> if the result would exceed that max_size, just code things
> to ignore it first.

That's about how I implemented it in my last patch. Is it correct that 0 means that there is no max_size? Should I set *delta_size to 0 when doing an early return, or leave it alone?

Note that this really is a micro-optimization, since all the expensive stuff is the indexing and then the matching. Since my algorithm matches both forward and backward, there is no way to know that the patch size can't be optimized until after matching completes, even though it will never actually create the patch or allocate memory for it.

   -Geert