On 25.01.2011 16:58, Hyrum K Wright wrote:
> Johan (and other interested parties),
> I've been following some of the commits to the
> diff-optimizations-branch with interest. While I've not reviewed them
> for technical merit, it appears that others have, and that there is
> good work going on in the branch. I'm wondering what the potential
> for merging back to trunk is.
Since I'm traveling for most of next week, I should
have enough in-flight time for an in-depth review.
Slow diffing has always bugged me as a user ;)
> This is the TODO section from the BRANCH-README:
>
> TODO:
>
> * eliminate identical prefix [DONE]
> * eliminate identical suffix [DONE]
> * make diff3 and diff4 use datasources_open [DONE]
> (this may eliminate the need for datasource_open, and the flag
> datasource_opened in token.c#svn_diff__get_tokens)
> * implement (part of) increment_pointers and
> decrement_pointers with a macro [DONE]
> (offers another 10% speedup)
Even if some of the changes should no stand up to
scrutiny as is, most of them should be independent
from each other. Thus, pick and choose will certainly
be viable.
> * integrate (some of the) low-level optimizations for prefix/suffix
> scanning, proposed by stefan2 [2] []
That is not an essential part and can certainly be
done directly on /trunk.
> * revv svn_diff.h#svn_diff_fns_t []
>
> It looks like, for the most part, any destabilizing functionality is
> completed, and what remains are simply optimizations. This
> optimization work can probably be performed on trunk, and if so, we
> should merge the branch back and do the cleanup work there. The only
> bit on the current list of stuff is revving svn_diff_fns_t. Can that
> work be parallelized?
>
> I'm not trying to rush the work, nor do I think it is essential for
> 1.7, but it feels like a pretty good performance increase, and one
> that we shouldn't have any problem shipping. (If there are currently
> API uncertainties, than it would be good to wait until 1.7.x branches,
> though.)
>
> Anyway, I just really like the concept / implementation of the branch,
> and I'm excited to get it into the hands of users. Thoughts?
I'll review the code and if Johan is still reasonably
sure that the API is final, I'm all for merging it.
-- Stefan^2.
Received on 2011-01-26 22:08:58 CET