Mail Archives: cygwin/2007/12/10/08:41:06
> 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 AT hotmail DOT 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 AT yahoo DOT com if no reply
here. Thanks.
> Date: Mon, 10 Dec 2007 14:28:02 +0100
> From: corinna-cygwin AT cygwin DOT com
> To: cygwin AT cygwin DOT 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/
- Raw text -