> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] if no reply here. Thanks. > Date: Mon, 10 Dec 2007 14:28:02 +0100 > From: [EMAIL PROTECTED] > 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/