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 <s...@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 <pe...@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.