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.
