I'm not terribly familiar with the code in libsvn_repos, but there are two
places that seem to be the source of slowness even with --limit turned on:
subversion/libsvn_repos/log.c:svn_repos_get_logs3 -
1. When passing one path such as /trunk (or / which mod_dav_svn always
seems to do even if no deeper path was specified) it performs the
svn_repos_history2 call and spends a lot of time there gathering all revs
for the path (which is nearly all the revs in the repo for /trunk and *is*
all revs in the repo for /). So, svn_repos_history needs to be revved to
take a limit parameter?
2. Further down in the for loop to process the revs, there is a check to
see if the rev was one identified by the previous svn_repos_history2 call
(line 348). This check is a brute force linear search. While probably not
a huge issue, it seems like it could changed to use a binary search since
the revs array has been sorted above? It could make a noticeable difference
on repos with many thousands of revisions.
It seems like #1 is the major perf killer since it is essentially reading
almost all revs in the common case of 'svn log --limit 10' on a working copy
of trunk.
This is confirmed by the fact that 'svn log --limit 10
svn://localhost/svn-repo' returns nearly instantly, where as 'svn log
--limit 10 svn://localhost/svn-repo/trunk' takes about 10 seconds for me.
The first case is an empty path in svn_repos_get_logs3 and so skips the
svn_repos_history2 call. Curiously, mod_dav_svn always passes at least '/'
in the path and so never bypasses the svn_repos_history2 call.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 8 17:58:56 2005