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

Re: [PATCH] extend svn_subst_translate_string() to record whether re-encoding and/or line ending translation were performed (v. 2)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sun, 28 Nov 2010 10:59:57 +0200

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;
% 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?


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

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.