[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 4783 - trunk/subversion/tests/clients/cmdline/svntest

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-02-08 11:07:39 CET

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> cmpilato@tigris.org writes:
> > Log:
> > * subversion/tests/clients/cmdline/svntest/main.py
> > (copy_repos, _run_command): Add some performance timers to the
> > command-line print output.
>
> I should point out that this is part of a general effort to find out
> where 'make check' is spending its time. It takes so long to run the
> regression tests right now that it's a bit of an impediment to
> development. No doubt part of the cause is Subversion itself, and
> will be solved as we address various performance problems in svn. But
> some of the problem may be solved by improving how the test suite
> runs.

I think you may want to consider the sleep behaviour of the command
line client. The svn commands checkout, update, commit, revert and
some forms of copy, all finish with a one second sleep to ensure we
can use timestamps to detect changed files. There are about 480 such
commands in the regression test suite, that's equivalent to sleeping
for 8 minutes. It gets worse, there is a bug in the svn:externals
handling that causes a sleep for each external, rather than just one
sleep for the top working copy. There are 80 commands in the
externals tests that could be affected, if we assume an average of 1
or 2 externals per command then that is equivalent to another two
minutes sleeping. So the test suite as a whole sleeps for perhaps 10
minutes, that's one third of the 30 minutes you say it takes you to
run it! Fixing the externals so that there is only one sleep per
command would help, but doesn't address the root problem.

By compiling and running in multiple build directories it is possible
to run ra_dav, ra_svn, ra_local in parallel. The sleeps introduced by
the command line client mean that two parallel runs have little effect
on each other. Running the tests this way is rather inconvenient, to
say the least. How about trying to run the python command line tests
in parallel automatically? Take a list of the scripts in
subversion/clients/cmdline and fork off two or three subprocesses to
run the first two or three scripts. Then as each process completes
start the next script, and finally wait for the last processes to
complete. This would require multiple local_tmp directories, with
some communication of the directory name to the individual scripts.
We probably don't want to run all the scripts in parallel, as the disk
IO may start to limit the gains. It may be worth getting the
testsuite create_repos function to set DB_TXN_NOSYNC in the DB_CONFIG
files to optimise disk IO when multiple repositories are in use.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 8 11:08:27 2003

This is an archived mail posted to the Subversion Dev mailing list.