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: Updated: cygwin-1.5.25-5


> I don't understand what you mean. Using> on the command line or
> opening the file by using some option of the tool has both nothing to do
> with console output. In both cases a file is opened. The only

I didn't give it a lot of additional thought, I just stopped using ">" (  when 
I have significant amounts of output ) a while ago
and assumed it had something to do with buffering- I have no idea
what is going on once I call "<<" and I never did a version by version test.
Similarly, I essentially stopped using std::string since for most of what 
I did it was easier to do a block read anyway. 
I'm simply pointing out that the details appear to matter and, as you
request, a test case would help but the gprof output could point to
some surprising suspects. 


Mike Marchywka
586 Saint James Walk
Marietta GA 30067-7165
404-788-1216 (C)<- leave message
989-348-4796 (P)<- emergency only
marchywka@hotmail.com
Note: Hotmail is blocking my mom's entire
ISP claiming it is to reduce spam but probably
to force users to use hotmail. Please DON'T
assume I am ignoring you and try
me on marchywka@yahoo.com if no reply
here. Thanks.

> Date: Mon, 10 Dec 2007 15:03:34 +0100
> From: corinna-cygwin@cygwin.com
> To: cygwin@cygwin.com
> Subject: Re: Updated: cygwin-1.5.25-5
>
> On Dec 10 08:40, Mike Marchywka wrote:
>>> I can't reproduce worse I/O performance. I tested different scenarios
>>> with lots of disc I/O and the performance was identical between 1.5.24
>>> and 1.5.25 within the bounds of a performance test.
>>>
>>
>>
>> One thing I found out, after originally blaming my inner computational loops,
>> was that console IO is very slow. Using ">" on the command line makes a big
>> difference compared to opening a destination file. This seemed to be the
>> speed limit in many programs I thought were computationally limited.
>> [...]
>> Has the console buffering
>> changed lately?
>
> I don't understand what you mean. Using> on the command line or
> opening the file by using some option of the tool has both nothing to do
> with console output. In both cases a file is opened. The only
> difference in that in the> case the shell opens the file and the child
> inherits the file descriptor, in the other case the child opens the file
> by itself. However, I don't see how getting a file descriptor to a file
> from the parent should be different than opening the file in the child,
> at least as long as parent and child are both Cygwin processes.
>
> In fact, one of my tests was a loop using `cat < foo> bar', which got
> much faster under 1.5.25 due to the new 64K buffering.
>
> Give me a really simple testcase which shows reproducibly worse
> performance on 1.5.25 compared to 1.5.24 and I'll have another look.
>
>
> Corinna
>
> --
> Corinna Vinschen Please, send mails regarding Cygwin to
> Cygwin Project Co-Leader cygwin AT cygwin DOT com
> Red Hat
>
> --
> 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/
>

_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/connect.html?ocid=TXT_TAGLM_Wave2_newways_112007

--
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]