On Sun, May 9, 2010 at 11:25 PM, Stefan Fuhrmann <stefanfuhrm...@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
