I was able to capture a profile from svn (after remembering I have to link
statically). I compiled with "-pg -O0" Here is the top of the file:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
88.88 133.49 133.49 2002891836 0.00 0.00 svn_diff__snake
5.97 142.45 8.96 56 0.16 2.54 svn_diff(long, char,
short)
1.98 145.42 2.97 4163001 0.00 0.00 MD5Transform
0.41 146.04 0.62 4163001 0.00 0.00 Decode
Is it OK to attach the full report to this user list? The resulting text
file is 1.3MB and I wasn't sure if the list would tolerate an attachment of
that size.
Cheers,
Kyle
On Sat, Oct 1, 2011 at 7:55 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>wrote:
> gprof is what I'm familiar with (nutshell: compile with 'gcc -pg' and
> read gmon.out). There are no specific profiling docs for svn; if you
> need more specific advice please post to the dev@ list. Thanks!
>
> Kyle Leber wrote on Sat, Oct 01, 2011 at 19:33:10 -0400:
> > What method of profiling do you recommend? I have used gprof previously
> > (it's been awhile) but am not familiar with the subversion project source
> > code and build setup. Is the a online guide or wiki describing the
> > preferred setup for performing this?
> >
> > Kyle
> >
> > On Sat, Oct 1, 2011 at 3:10 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name
> >wrote:
> >
> > > Johan Corveleyn wrote on Sat, Oct 01, 2011 at 20:47:29 +0200:
> > > > [ Please do not top-post on this list, i.e. please put your reply
> > > > below or inline. More below ... ]
> > > >
> > > > On Sat, Oct 1, 2011 at 6:49 PM, Kyle Leber <kyle.leber_at_gmail.com>
> wrote:
> > > > > On Fri, Sep 30, 2011 at 7:15 PM, Johan Corveleyn <
> jcorvel_at_gmail.com>
> > > wrote:
> > > > >>
> > > > >> On Fri, Sep 30, 2011 at 3:29 PM, Kyle Leber <kyle.leber_at_gmail.com
> >
> > > wrote:
> > > > >> > I've encountered what I think is a problem with subversion, but
> I'm
> > > not
> > > > >> > completely sure (and according to the online instructions I
> should
> > > bring
> > > > >> > it
> > > > >> > up here prior to filing a bug).
> > > > >>
> > > > >> Actually, the instructions on
> > > > >> http://subversion.apache.org/issue-tracker.html say that you
> should
> > > > >> send your report to users@, not dev@. So I'm adding users@.
> Please
> > > > >> drop dev@ from any further replies.
> > > > >>
> > > > >> > Basically, we're trying to merge a rather large collection of
> > > > >> > fixes back in our trunk. I check out a fresh copy of the trunk,
> > > > >> > then use the merge syntax: svn merge https://path/to/my/branch.
> > > > >> >
> > > > >> > This generally churns along just fine, but we occasionally get
> > > > >> > hung up on medium sized binary files where the svn client jumps
> > > > >> > to 100% cpu usage and sits on it for 3+ hours before moving on
> to
> > > > >> > the next file. These files are anywhere from 3-10MB in size, so
> > > > >> > not ridiculously huge. We generally have these files marked as
> > > > >> > octet stream, but changing to text did not help the situation
> > > > >> > when we tried that.
> > > > >> >
> > > > >> > I did find an old forum discussion about a potential issue that
> > > > >> > could be related. I was wondering if this was ever addressed
> and
> > > > >> > could it still be the same problem. Link is here:
> > > > >> > http://www.svnforum.org/threads/36123-Slow-SVN-merge
> > > > >> >
> > > > >> > I'm using svn client 1.6.12. I looked at the online change log
> > > > >> > up through the 1.7 alphas and didn't see any bug fixes that
> > > > >> > sounded relevant.
> > > > >>
> > > > >> This could be a relevant change (listed in the 1.7 release notes,
> not
> > > > >> in the change log):
> > > > >>
> > > > >>
> > >
> http://subversion.apache.org/docs/release-notes/1.7.html#diff-optimizations
> > > > >>
> > > > >> Can you please try one of the 1.7 pre-release binaries, and see if
> it
> > > > >> helps? See http://subversion.apache.org/packages.html#pre-release
> > > > >>
> > > > > Thanks, Johan. I tested with 1.7rc4 and it did not make any
> > > perceptible
> > > > > difference. Anything else I can try?
> > > >
> > > > Hm, that's unfortunate.
> > > >
> > > > Actually, it was to be expected that this wouldn't help, because the
> > > > diff-optimizations in 1.7 only play a role when merging text files
> > > > (and diffing and blaming). And you said those
> > > > "files-that-make-merge-hang" are generally marked as octet-stream,
> and
> > > > changing them to text made no difference.
> > > >
> > > > That seems to indicate that the 100% cpu usage on the client isn't
> > > > spent in the diff code (unlike the forum thread that you linked to,
> > > > where the poster tracked it down to libsvn_diff/lcs.c --- he would
> > > > definitely have been helped by the 1.7 improvements).
> > > >
> > >
> > > What does 'svn merge' do for binary files? I checked svn_wc__merge()
> > > a few months ago and for binary files all it knew to do was
> > >
> > > (a) if mine == merge-left then set merged := merge-right
> > > (b) invoke the configured diff3-cmd
> > > (c) raise a conflict
> > >
> > > but it didn't do any line-based merge (per Johan's second response).
> > >
> > > > So there's another reason. Maybe it has something to do with (lots
> of)
> > > > subtree mergeinfo? Can you verify if there is a lot of svn:mergeinfo
> > > > on directories and files all over the place?
> > > >
> > > > Also: can you tell us what version is running on the server?
> > > >
> > > > Maybe other people on this list have had similar experiences, and can
> > > > give some suggestions?
> > > >
> > >
> > > Another line of thought: the algorithm for computing binary deltas
> > > changed a few years ago, and I recall reading (on old bug reports?)
> > > about some cases in which the delta combiner would be inefficient for
> > > deltas generated by old servers --- i.e., it would be expensive to 'svn
> > > cat' files that were committed to old servers in repositories that
> > > haven't been dumped/loaded by a newer server.
> > >
> > > In any case: can you run the merge under a profiler and tell us in what
> > > function(s) time is spent?
> > >
> > > Daniel
> > >
> > > > --
> > > > Johan
> > >
>
Received on 2011-10-02 23:08:53 CEST