[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Status of the branch diff-optimizations-bytes branch

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Tue, 25 Jan 2011 09:58:31 -0600

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.  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)
  * integrate (some of the) low-level optimizations for prefix/suffix
    scanning, proposed by stefan2 [2] []
  * 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?

-Hyrum
Received on 2011-01-25 16:59:10 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.