On Sun, May 9, 2010 at 11:25 PM, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:
[...]
>
> Thanks for committing! I just got the last patch set out
> (zlib) and will start detailed performance measurements.
> Hopefully, all my other patches will then get committed
> as well ;)
>
> Currently, I get 2.6s (real) for an svn export -q of
> svn://localhost/apache/subversion/trunk and 1.6s (real)
> if I disable compression for the data transfer.
I'm not an expert (especially not in optimizing C code), but I'm
interested in all bits and pieces that can improve svn's performance.
I'm just wondering whether you're focusing on the biggest bottlenecks,
when looking at the back-end.
In my experience, FSFS' biggest bottleneck is disk I/O (at least when
we're looking at large read operations, like "log" and "annotate";
don't know for update/checkout/export). For instance "svn log" opens
and closes each interesting rev file numerous times (up to 10 times)
and reads them through several times (see e.g. [1], [2] and [3]).
Packed rev files don't help a lot, because the packed file is
opened/closed and seeked through just as many times.
As I understand your set of patches, you're mainly focusing on saving
cpu cycles, and not on avoiding I/O where possible (unless I'm missing
something). Maybe some of the low- or high-level algorithms in the
back-end can be reworked a bit to reduce the amount of I/O? Or maybe
some clever caching can avoid some file accesses?
Just to be clear: I think it's great that someone is looking at
optimizing things. I'm just wondering whether even bigger gains are
possible (especially regarding log and annotate, but maybe the same is
relevant for update/checkout/export). And it's not that I can help a
lot, I'm mostly an innocent observer here :-).
[1] http://svn.haxx.se/dev/archive-2009-06/0459.shtml
[2] http://svn.haxx.se/dev/archive-2007-08/0239.shtml
[3] I've also done some "poor man's profiling" for this once, by
adding printf's to APR's apr_file_open and file_cleanup (which is
called by apr_file_close, but also when a file is closed because its
pool is cleaned up). It was quite interesting to see, and to correlate
this with the higher level flow. But I had to move on to other
priorities, so couldn't follow through on it ...
Cheers
--
Johan
Received on 2010-05-11 01:36:53 CEST