This is the mail archive of the cygwin 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 copy problems usb 2.0


On Thu, Aug 03, 2006 at 09:54:13AM +0200, Reini Urban wrote:
>Christopher Faylor schrieb:
>>On Thu, Aug 03, 2006 at 02:11:00AM +0200, Reini Urban wrote:
>>>Christopher Faylor schrieb:
>>>>On Thu, Jul 27, 2006 at 11:11:07PM +0200, Corinna Vinschen wrote:
>>>>>On Jul 27 13:48, aldana wrote:
>>>>>>isn't there a possibitly that cygwin provides a quicker
>>>>>>cp-implementation?  i mean 4 minutes for a copy of 70MB to a memstick
>>>>>>(instead of CopyFile() 20 sec.) is not really good performance.  i
>>>>>>guess there is a reason for that...
>>>>>Right, how did you know?  The reason is that cp is a portable
>>>>>implementation using simple reads and writes to perform the copy.
>>>>>There's no such thing as a CopyFile routine on POSIX systems.
>>>>A few weeks ago there was a guy in libc-alpha mailing list complaining
>>>>that glibc's API wasn't as rich and powerful as what is found on Windows.
>...
>>>I'm really seeing the non-optimized cygwin cp behaviour causing bad 
>>>reputation, which could be easily patched and maybe even accepted 
>>>upstream. Who knows. Eric what do think? Would it be worthful to think 
>>>about?
>>
>>If this is what you want then you should look into a non-cygwin
>>solution.  There are a couple of projects which provide GNU tools for
>>Windows without resorting to something like the Cygwin DLL.
>
>It's not for me, I know how to call copy or xcopy or how to install 
>mingw's cp, which doesn't help btw.
>It's for the project reputation. Think of buildtimes.

That logic could be used for bash, too.   Maybe Eric should spend a few
months modifying bash to avoid fork and use CreateProcess.  I'm sure it
would be faster.  It's a slippery slope and I really don't want to start
down that path for Cygwin.

>>Also, don't you see something wrong with the mindset of "Windows Fast.
>>Cygwin Slow.  So, must use straight Windows functions." without even
>>bothering to do any research into what is causing the slowness?  
>
>I didn't say that and I see the same problem as you.

No.  You don't.  You see a problem that would be solved by someone
modifying cp to use the Win32 API.

>>How do you, or anyone who cares about this know that this "problem",
>>know that it isn't correctable without resorting to patching cp?
>
>I have no idea, but it should be investigated.  If it's just the buffer
>size or some waits in the driver communication.

So, as usual in an open source project, if it bothers you that much then
investigate it.

>But it's really up to the coreutils maintainer or some of us to come up 
>with a patch.

I would submit that if one of the project leaders thinks it is a
terrible idea, then the packae maintainer should seriously take that
into consideration.

Again, if this problem is really important to someone then maybe they
should take time to understand what is causing the slowness before
suggesting solutions.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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