Edward Ned Harvey wrote on Fri, 2 Jul 2010 at 07:42 -0400:
> > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> >
> > By hand!? I thought they had a rule in Programming School against
> > doing repetitive tasks by hand like that. :-)
>
> Believe me, I spent every minute of that time, imagining how complex my
> python script would be, and how to handle the exception cases... ;-)
>
How about something like this? Just call it in a loop until it reaches
the end of the file...
$ cat foo.vim
[[[
call search(')\n{') " exclude structs/enums
+ " advance line
let fn_lineno = search('\i*\ze(', 'bn')
let funcname = matchstr(getline(fn_lineno), '\i*\ze(')
normal! o
call setline('.', printf('SVN_DBG(("%s()\\n")); {', funcname))
/^}/ s/^/}/
]]]
(you can call it via ":source foo.vim" inside 'vim main.c')
> > > There are a lot of files, and there are a lot of functions within
> > > those files. The flow of the program is far from straightforward.
> >
> > You're looking in the wrong place. I'd focus on the server side,
> > and there --- on one of the libsvn_* libraries (e.g., fs, delta, or
> > subr). subversion/svn/ contains only the code specific to the
> > command-line client 'svn'; you can safely ignore it unless you don't
> > see the issue with other clients.
>
> We first experienced the problem in production. Clients connecting via
> svn:// to svnserver.
>
> Since I'm debugging, I'm able to reproduce it on the command line with svn,
> using svn:// so there is no server.
>
Okay.
> I believe svn command line must be linking to the various server libraries
> you mentioned, but I need to know which one(s) to look into. The only way I
> know to do that is to start at the beginning. printf()'s inside of svn
> main() which tell me what process flow main() is following ... and finally
> ... it's spending its time in (some function) ... so I scatter printf()'s
> inside of (some function) and discover it's spending its time in (yet
> another function) so I go into it and scatter more printf()'s ...
>
I think you should try to understand the high-level structure of the
code before just binary-searching the call stack. For instance, since
you say the slowdown is on the server, you could probably start right in
libsvn_repos... (since libsvn_ra_local is just a thin wrapper)
Ditto for skipping subversion/svn/ entirely; if the issue is not
client-specific, you can start right in svn_client_commit5().
> Again, thanks for the help.
>
>
You're welcome.
Daniel
