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

fwiw, I mentioned gprof to the OP earlier. I hadn't used this before but
it should give you some idea where the time goes. It may be interesting
to compare times with output sent to stdout versus a file. Obviously, you
want to flush the console more often most of the time.  Has the console buffering
changed lately? 

Also, in the past, I think std::string operations were a problem but 
I saw this in a list of bugs specific to a compiler version. 
In fact, it looks like the gprof output is given as evidence here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15002

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 14:28:02 +0100
> From: corinna-cygwin@cygwin.com
> To: cygwin@cygwin.com
> Subject: Re: Updated: cygwin-1.5.25-5
>
> On Dec 10 10:57, Corinna Vinschen wrote:
>> On Dec 9 10:49, Jim Reisert AD1C wrote:
>>> I have a number of data processing programs written in C in the Cygwin
>>> environment. They read data files into linked lists, analyze the data
>>> and write results back out to disk.
>>>
>>> This new release of Cygwin is about 10x slower than 1.5.24-2, after
>>> recompiling the programs. I went back to the older Cygwin release and
>>> normal speed was restored.
>>
>> Well, 10x sounds rather bad.
>
> 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.
>
> In some cases applications are even getting faster under 1.5.25, for
> instance cat(1) from coreutils. This is likely due to the fact that
> the st_blksize member in struct stat now returns 65536 (apparently the
> preferred I/O blocksize in Windows). This should also positively affect
> the stdio functions like fread/fwrite.
>
> Given the above, we really need a simple, self-contained testcase,
> as I asked for in my previous mail on the subject.
>
>
> 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/
>

_________________________________________________________________
Your smile counts. The more smiles you share, the more we donate.? Join in.
www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline

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