I just merged (most of) the changes that accumulated
on my 'Performance' branch into /trunk.
While hopefully nothing broke, there might still be one
side-effect or another. So, I split the merge into a
sequence of change sets that could be reverted individually
- just in case.
So, this is what I did over the last months. Most of my
efforts went into my change flow (merges and more)
reconstruction project (TortoiseAnalyze) and I'm about
half-way there. The main challenge is to process literally
billions of code lines within reasonable time.
As a byproduct, the following improvements to TSVN were made:
* improved standard conformity of said code
(TAnalyze is Win / Unix portable)
* option to load and modify the log cache data asynchronously
(unused code as long as TSVN does not explicitly call it)
* lots of minor optimization in the generic data storage
layer used by the log cache
* A very easy-to-use asynchronous execution framework
loosely modeled after .NET4 multi-threading enhancements.
Points one and two are of limited interest and impact to TSVN
but I would like to keep a single code base for these libs.
The last point something I'm really exited about. It can
completely replace the manual threading code we currently
use throughout TSVN. Its real benefit lies with its ability
to put load on as many resources as we want without making
the code much more complex than a linear program.
For instance, the log dialog could
- read the SVN / log cache query
- scan the WC for the current revision
- filter the result
all at the same time as disk I/O, network I/O and CPU
resources are widely independent. Today, we only did the
first two things (?) and have to do some manual thread
The revision graph code uses this technique to mask as
many latency as possible during the data acquisition phase.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-02 02:09:06 CEST