This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance


On Tue, Sep 28, 2010 at 11:44:47AM -0600, Warren Young wrote:
>On 9/28/2010 9:10 AM, Christopher Faylor wrote:
>> It isn't extremely surprising that Linux access speed for a filesystem
>> in a simulated environment, which presumably does not go through
>> multiple layers of DLLs, would be faster than Cygwin.
>
>I think it more likely that the HGFS driver doesn't try to preserve full 
>POSIX semantics.  There's plenty of precedent: vfat, iso9660...  One 
>could probably verify this faster by examining the driver's source code 
>(http://open-vm-tools.sourceforge.net/) than by tracing syscalls.
>
>If that's the explanation, it points at a possible path forward.
>
>On Linux, these secondary filesystems aren't expected to provide full 
>POSIX semantics, simply because they are secondary.  No one cries very 
>hard that you can't make symlinks on a FAT-formatted USB stick.
>
>Yet, there's probably no technical reason you couldn't get a POSIX-like 
>system to run on a crippled filesystem.  It's probably even been done 
>lots of times before in the embedded world.  Some of the PC Unix systems 
>from the 80s and early 90s were pretty screwy in this way, too.  Screwy 
>doesn't prevent you from doing useful work, though.
>
>Would it not be useful to have a mode in Cygwin that purposely skips any 
>POSIX semantics that it can't get for free by making the POSIX syscalls 
>nothing more than thin wrappers around the nearest equivalent Win32 API? 
>  If you put it in this mode and it breaks, you get to keep both pieces. 
>  There are those who would happily accept the speed increase for loss 
>of some functionality.  I wouldn't, but some would.  I'd bet a lot of 
>the 3PPs are in that group, since they know their target environment 
>very well.

There's a lot of speculation here which could be solved by either just
reading the source or even trying it.  I'd rather not go down the theory
path in technical mailing lists.  We're supposed to be actual doers here.

However, wrt to your suggestion that we roll Cygwin back to 1998, I'd
have to say "No way".  Just look at the discussion about deleting the
current working directory.  We didn't say "Oh well, Windows doesn't
support it.  People will understand." Instead we tried extremely hard to
come up with a way to make it work.  That's what we do in Cygwin.  We
try to present an environment which looks as much like Linux as
possible.  Making it look sort of like Linux except you have to modify
your program in some situations because we decided that it was more
important to be fast, is not what we have historically done.  And, it is
not a change that I'm comfortable making, especially since it represents
a regression in functionality.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]