subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: svn commit: r1593015 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.c fs.h
Date Thu, 15 May 2014 12:43:32 GMT


> -----Original Message-----
> From: stefan2@apache.org [mailto:stefan2@apache.org]
> Sent: woensdag 7 mei 2014 15:44
> To: commits@subversion.apache.org
> Subject: svn commit: r1593015 - in
> /subversion/trunk/subversion/libsvn_fs_fs: fs.c fs.h
> 
> Author: stefan2
> Date: Wed May  7 13:43:55 2014
> New Revision: 1593015
> 
> URL: http://svn.apache.org/r1593015
> Log:
> Follow-up to r1591919: Fix fs tests on Windows and non-threaded platforms
> by always using our svn_mutex__t and thus being able to detect recursive
> locking attempts.
> 
> For non-threaded platforms, always using svn_mutex__t adds almost zero
> overhead to the FS file locking that we need to do anyways.  On Windows,
> the overhead slightly larger but all the APR functions that svn_mutex__*
> calls have very efficient implementations on Windows.  So here, the relative
> overhead is minimal as well.
> 
> OTOH, all our tested platforms will detect incorrect / non-portable lock
> usage.

Not that even after a week the OpenBSD tests are still failing.

And I'm not sure if this is really the right way to fix such a corner case on Windows.

Why should we do extra work on Windows which has obvious performance side effects?

Windows does check per handle, which is really what we need here. We add the missing checks
for platforms that don't check, but adding a check on platforms that don't need it really
make sense.


I'll remind you of this example the next time you call the Windows implementation slow.

Sure, Windows is slow if you first want to make it behave exactly like *nix and then add another
layer for the features missing on *nix.


Same thing as we used to do for obtaining file status... Read the directory; and then for
every node read the directory again because we assume every system uses i-nodes to hold other
things.

These 'performance optimizations' you have been applying over the last few weeks are slowed
Subversion down by +- 2-5% on my test environment when I measured the result about a week
ago.

Whatever runs faster on the combination of your huge system, your specific compiler, your
os and your multi gbit network is not necessarily whatever all others are using. 

And optimizing for most of those specific scenarios is a task for the OS, compiler, platform
libraries etc. Not necessarily always Subversion itself. (E.g. in the recent cases where code
was added to support more memory for apr compiled in a nonstandard configuration)


	Bert 



Mime
View raw message