Nuutti Kotivuori <naked@iki.fi> writes:
> While straceing, I discovered that 'svn up' only runs stat on every
> file - and reads the entries from every .svn directory. 'svn st -u' on
> the other hand stats every file two to four times in a row, and also
> stats much more files in the .svn directory, such as prop-bases, props
> and dir-props.
>
> I do not know if that already accounts for the 5 times more CPU time,
> but it's a start.
The real "culprit" is the call to svn_wc_text_modified_p() in
assemble_status(). On my machine this is responsible for over 70% of
the CPU when running 'svn st' on an up-to-date subversion tree.
I think what happens is that 'svn up' uses .svn/entries to describe
the working copy to the repository. The repository returns a diff
which drives an editor. Since, in your case, most of the files in the
working copy do not appear in the diff, there is very little work for
the editor to do.
'svn st' on the other hand calls svn_wc_text_modified_p() on every
item in the working copy. Interestingly the main CPU usage in
svn_wc_text_modified_p() is calling svn_wc__timestamps_equal_p().
Making the timestamp call do nothing except return that the timestamps
don't match reduces the CPU usage by nearly 70%, however the run-time
is trebled, as it means every file has to be read. However a second
run, when the files are cached, is much quicker. With the files in
cache, taking out the timestamp comparison reduces CPU and runtime by
about 60%.
How can we optimise this? Subversion does a lot by passing filenames
around. This means that svn_io_check_path() is often called repeatedly
on the same path, as is svn_wc_entry() or svn_wc_entries_read(). For
instance each call to svn_wc__timestamps_equal_p() calls
svn_io_check_path() when assemble_status() has just already done
so. svn_wc__timestamps_equal_p() also reads the directory entries for
the file, meaning they get read repeatedly despite having been read in
svn_wc_statuses().
--
Philip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 8 04:19:40 2002