>
> This two line patch on svn_dirent_get_absolute is the result of
> several hours of profiling and it makes the merge test we profiled
> 30% faster. (It probably increases the speed of many other
> subversion commands as well).
>
> This very Windows specific slowdown was added in r13 when the call
> to _fullpath() from the Microsoft C++ library was replaced by the
> more generic apr_filepath_merge.
>
> On all platforms except windows apr_filepath_merge can only make the
> path absolute, but on Windows it also allows the flag
> APR_FILEPATH_TRUENAME that actually verifies if the path exists by
> checking the exact casing of the path and all its ancestors.
>
> !! It actually performs disk IO !!
>
> On a typical test merge:
> svn merge -c
> 31121,31211,31733,31846,32497,32800,32836,32837,33156,33178 http://svn.collab.net/repos/svn/trunk
> F:\wc\1.5.x
> (F:\wc\1.5.x = 1.5.x branch @33444)
>
> This svn_dirent_get_absolute involves several thousands of calls to
> FindFirstFile, while only 22 files receive updates.
>
> Removing this flag shaves 7 seconds from the merge time on my quad
> core pc.
> When I run it on a local mirror of the subversion repository the
> difference is well over 30%. (Over webdav most time is spent waiting
> on bits to arrive from the USA)
>
Actually in the above merge example, 9 merges are performed (one of
them has already been merged), and for each merge
svn_sleep_for_timestamps is called (sleeping for 1.1 seconds)
This means that going from 19 to 12 seconds, should actually be
explained as going from 9 to 2 seconds, which is a far greater
improvement.
Do we need the sleep function to be called after merging every
revision (most commands that call it only call it when they're
finished)?
--
Sander Rijken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-06 19:56:03 CEST