Branko Čibej wrote:
> 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.
ok it waits until the next 'second change' to be more precise,
but if you chain many svn commands from a script, its
effectively always an extra second.
>
>> -) 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.)
I have no (FAT) filesystem available with only a 2 second resolution,
but i could think of a situation like this
! imaginary example !:
svn update
#=> creates file1 with current time 00:00:00.10
#=> FAT rounds this to 00:00:02
#=> svn stores that time as 'last modified' in its entries file.
#=> user modifies a character in the file no size change)
# at 00:00:01.30 -- FAT rounds this to 00:00:02 again.
svn commit
#=> does nothing - file time hasn't changed, size hasn't changed
#=> user thinks everything is committed and deletes his WC,
or a release version is built without the required fix etc.
>
>> 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.
I'm trying to create test scripts that exactly 'replay' all user-actions
that were performed to create our production repository, to test for
svn's stability.
this means i have about ~20.000 files that were added file-by-file over
time, resulting in ~30.000 revisions.
so, if i replay 30.000 svn actions this costs me - 30.000 seconds
(>8 hours).
if i remove the sleep, test time goes down to less than half an hour.
i know its opensource and i can change it at will, but i guess others
may have similar situations/scripts with many calls to the svn
executable and where this could significantly speed up things.
>
>> 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.
my script mostly uses a sequence of
svn add file1
svn commit file1 *waits 1 sec*
svn modify file2
svn commit file2 *waits 1 sec*
just like a normal user would perform it
(actually I'm replaying actions from another 'svn log')
>> 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 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.
If I find the time I'll ofcourse try that.
does stress.pl work for Win32 ? i guess so. *need to get perl...*
>
> -- 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 15:25:29 2004