I timed 'svn export' of a 146MB subdirectory of a format-21 working
copy to a linux tmpfs. Below, 't1' is pristine trunk_at_HEAD and 't2' is
trunk_at_HEAD plus the patch at the top of this thread:
% cd /tmp/ram
% mount | grep $PWD
tmpfs on /tmp/ram type tmpfs (rw,nosuid,nodev,noatime)
% rm -f /tmp/five-{t1,t2}
% for j in $(seq 5); do
for ii in t1 t2; do
.svn $ii;
rm -rf ./$ii;
(time $svn export -q ~/src/asf/infra/trunk/ ./$ii) 2>&1 | tee -a ../five-$ii;
rm -rf ./$ii;
done;
done
% cat /tmp/five-t1
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.26s user 2.36s system 37% cpu 15.035 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.29s user 2.58s system 29% cpu 20.046 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.41s user 2.36s system 29% cpu 19.664 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.36s user 2.45s system 30% cpu 19.222 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.32s user 2.39s system 29% cpu 19.156 total
% cat /tmp/five-t2
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.40s user 2.35s system 32% cpu 17.823 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.51s user 2.64s system 26% cpu 22.859 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.26s user 2.49s system 29% cpu 19.313 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.28s user 2.37s system 29% cpu 19.312 total
$svn export -q ~/src/asf/infra/trunk/ ./$ii 3.24s user 2.30s system 28% cpu 19.329 total
%
It seems that the second set of results is slightly slower?
Daniel
Danny Trebbien wrote on Sat, Nov 27, 2010 at 09:46:34 -0800:
> > To the point, I originally asked if your changes affected the performance
> > of checkout/export. That is not a reason to stop the patch in its tracks;
> > it's a question that should be answered (either way) and the patch then
> > proceed. So, firstly, do your changes have any noticeable performance
> > effect, or is the effect of the added per-line condition simply not
> > noticeable?
>
> I don't have benchmarks, but it does not seem that the performance of
> my tests are noticeably degraded. These tests aren't extensive,
> however, so I am not sure whether a much larger Subversion operation
> that uses the changes (such as running the patched `svnsync` to sync
> the GNU Nano repository) is impacted.
>
> Note that when EOL_TRANSLATED is NULL, the overhead is a single NULL
> check for each line.
>
> > If the latter, then I apologize (to Daniel) for your having spent time
> > writing patches (in various "creative" ways :)) that address what is
> > a non-problem.
>
> It's not a big deal, and I think that it helped me to understand the
> code more fully. Besides, I may have another option.
>
> This other idea is based on knowledge that b->repair is usually FALSE.
> Given this, I examined one of the if statements:
>
> if ((! b->repair) && DIFFERENT_EOL_STRINGS(src_format,
> *src_format_len, newline_buf, newline_len))
>
> The `DIFFERENT_EOL_STRINGS` check will run whenever b->repair is
> FALSE. So, I check `DIFFERENT_EOL_STRINGS` first and if that check is
> TRUE, I then check !b->repair, else check to see whether
> *b->eol_translated needs to be set to TRUE:
> <https://github.com/dtrebbien/subversion/commit/d22329a54dcf58cddc2b618f913597c6defbcb2d>.
> What do you all think?
>
> The upside is that unnecessary NULL checks of TRANSLATED_EOL are
> dynamically elided under normal conditions.
>
> The downsides are:
>
> 1.) Another assumption must be made (namely, that the EOL_STR string
> is not varied between calls to translate_newline() using the same
> translation baton).
>
> 2.) It complicates the logic.
>
> 3.) This penalizes repair translations.
Received on 2010-11-28 10:01:50 CET