RE: svn commit: r1593015 - in /subversion/trunk/subversion/libsvn_fs_fs: fs.c fs.h

> -----Original Message-----
> From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> Sent: woensdag 7 mei 2014 15:44
> To: commits_at_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
Received on 2014-05-16 15:52:53 CEST