C.A.T.Magic wrote:
>
> Hi subversion dev's,
>
>
> some time ago I wondered why most svn commands appear to be
> very slow, no matter how small the operation is
> or even if it does nothing at all.
> this is especially problematic if running test cases
> that require to push many revisions.
>
> Gred Hudson pointed me to 'svn_sleep_for_timestamps'.
>
>
> today i found some time to verify this and added some
> debugoutput into the svn_sleep_for_timestamps function.
> this is indeed the reason for the 'slowness'.
>
> svn_sleep_for_timestamps ALWAYS waits 1.10 seconds.
It does? Then that's a bug.
> -) i think it's in several situations called unneccesarily.
Possibly. Which situations?
> -) NTFS has a resolution of less than 1 _microsecond_,
> so a wait for a microsecond would be more than enough.
>
> -) FAT has a resolution of 2 (TWO) seconds, so the
> code would probably break.
Probably, yes. Of course, we can't reasonably make the code dependent on
the underlying filesystem.
> Filetimes are rounded to the next representable
> -later- filetime (at least on WIN32),
> which means if you write a file at 00:00:00.10
> it gets a FAT filetime of 00:00:02.00
> * could lead to data loss with a WC on FAT?
Perhaps that's the problem we're seeing with FAT, yes. (It's not data
loss, though -- be careful about the terms you use. Data loss is a
_very_ serious issue, this one isn't.)
> an example for an unessessary call
> to svn_sleep_for_timestamps:
>
> X:\SVNSandbox\TestFS\Work1>svn update
> [timestamp.sleep]
> At revision 1671.
>
> X:\SVNSandbox\TestFS\Work1>svn update
> [timestamp.sleep]
> At revision 1671.
>
> X:\SVNSandbox\TestFS\Work1>svn update
> [timestamp.sleep]
> At revision 1671.
>
> completes in ~3.01 seconds --> but could run in <0.01
I don't understand this example at all. What are you trying to prove?
That the svn command waits for 1 second after it's completed? We know that.
> svn is so lightning fast if I remove the call to
> apr_sleep (then - now);
> or replace it with a smaller time period,
> I think you should really have a look into this.
What is "lightning fast", and in which situations? If you update a 40M
working copy over the network, that additional second gets lost in the
noise. I suspect you're testing with very small, local-repos data sets,
which really aren't representative.
> a very simple approach could be:
> create a temporary file, stat() for its filetime
> and then wait until that time has passed.
I think this is very FS-dependent. But it's worth a try, yes.
> or repeatedly create a temp file every 10 milliseconds,
> and check its time until the time is different.
I don't like this.
> or make it a config option?
No!
> or make the sleep #ifndef WIN32 ?
No way. If this is a problem (you've still not convinced me it is, you
know), it's definitely not Windows-specific, and removing the sleep will
cause all sorts of problems.
> P.S.: even if I completely remove the sleep() call everything
> (fast test loop of change+update) seems to work fine (with NTFS)
On your machine, with your particular test case. Try the stress.pl test
instead.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 25 14:34:32 2004