Instead of guessing which function causes the lstat() calls, could we
have a tool tell?
I've looked at 'ltrace -S', but it seems to me that will only tell us
which public svn_wc_* API is responsible for the calls. Perhaps there
is another tool that can help us follow the entire call chain down to
the lstat() call?
Daniel
. o O (gdb with a breakpoint in lstat() and some fu to extract
statistics about the stack trace?)
Daniel Becroft wrote on Mon, Dec 06, 2010 at 18:32:09 +1000:
> On Mon, Dec 6, 2010 at 8:09 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>
> > On Mon, Dec 06, 2010 at 07:18:56AM +1000, Daniel Becroft wrote:
> > > On Fri, Dec 3, 2010 at 9:22 AM, Peter Samuelson <peter_at_p12n.org> wrote:
> > >
> > > >
> > > > [Daniel Becroft]
> > > > > I've just managed to build/install trunk on my ubuntu box at home
> > (first
> > > > > application I've ever compiled on it - yey!).
> > > > >
> > > > > What debugging tools would you recommend to investigate this further?
> > > > I've
> > > > > seen output posted that lists function names, and time spent on each.
> > > >
> > > > The obvious start is 'strace', as in 'strace svn merge ...'. It spits
> > > > out every system call. There's a lot of noise up front as it's loading
> > > > shared libraries and such, but it should still be obvious what we're
> > > > doing when crawling the tree (stat / lstat, open, etc.).<
> > http://p12n.org/>
> > >
> > >
> > > Thanks. I've run that, and all the calls are lstat(). There are 16 for
> > each
> > > file (or at least, those not affected by the merge). I've copied on of
> > the
> > > calls below (all 16 of these are identical).
> > >
> > > lstat("....../dev/workingcopy/A/beta.txt", {st_dev=makedev(8, 1),
> > > st_ino=23855167, st_mode=S_IFREG|0644, st_nlink=1, st_uid=1000,
> > st_gid=1000,
> > > st_blksize=4096, st_blocks=8, st_size=5, st_atime=2010/12/06-07:10:42,
> > > st_mtime=2010/12/06-07:10:42, st_ctime=2010/12/06-07:10:42}) = 0
> > >
> > > It does appear that it's a known issue though. I'll keep investigating to
> > > try and understand why it's getting called at all. Thanks for your help.
> >
> > That's probably the svn_wc_revision_status2() call in
> > ensure_wc_is_suitable_merge_target() (subversion/libsvn_client/merge.c).
> >
> > 1.6.x should be doing the same during reintegrate merges.
> > 1.7 does it for every merge.
> >
> > To verify my theory you can try the patch below.
> > We could try to optimize this if it is a problem.
> >
> > Stefan
> >
> > Index: subversion/libsvn_client/merge.c
> > ===================================================================
> > --- subversion/libsvn_client/merge.c (revision 1042308)
> > +++ subversion/libsvn_client/merge.c (working copy)
> > @@ -9022,6 +9022,7 @@ ensure_wc_is_suitable_merge_target(const char *tar
> > svn_boolean_t allow_switched_subtrees,
> > apr_pool_t *scratch_pool)
> > {
> > +#if 0
> > svn_wc_revision_status_t *wc_stat;
> >
> > /* Avoid the following status crawl if we don't need it. */
> > @@ -9068,6 +9069,7 @@ ensure_wc_is_suitable_merge_target(const char *tar
> > wc_stat->min_rev, wc_stat->max_rev);
> > }
> >
> > +#endif
> > return SVN_NO_ERROR;
> > }
> >
>
> Hey Stefan,
>
> I've applied the patch, and re-run the test. It's cut the calls down from 16
> to 10.
>
> Cheers,
> Daniel B.
Received on 2010-12-06 10:15:48 CET