Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <20020606154705.70673.qmail@web21008.mail.yahoo.com> Date: Thu, 6 Jun 2002 08:47:05 -0700 (PDT) From: Nicholas Wourms Subject: Re: Big Performance issue with CYGWIN 1.3.10 on Win2k - Urgent help reqd! To: Russ Jorgensen , cygwin AT cygwin DOT com In-Reply-To: <20020606033103.40460.qmail@web21508.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Windows ME, with the latest cygwin1.dll compiled from cvs, I get: $ time ./test.sh 1 real 0m0.984s user 0m0.000s sys 0m0.000s root AT DRAGON /usr/src $ time ./test.sh 2 real 0m3.194s user 0m0.000s sys 0m0.000s So I agree with Larry and Randall on that point. However, I have noticed, during "./configure" sessions that when it gets to: checking the maximum length of command line arguments... The machine starts getting slower and slower, freezing for 10 seconds at times. The entire process at that one step takes ~45 seconds. On a linux box, it takes only 5-6 secs. On 1.3.10, this step usually takes at most 15 seconds. Sometimes, like when I am configuring gcc for a build, it will crap out completely, complaining about being unable to fork. This has happened consistently with the later cvs builds of cygwin over the last 2 months. I have reinstalled cygwin on many occassions, so I know that it is related to a "bad installation" as the problem is reproducable every time. In the next example, I use gcc-3.1 as a test subject, though let me be clear that it always happens when that line shows up, regardless of what application I am building. If you want to see for yourself on windows Me, try: 1)Install a fresh, "full" install of cygwin to the box 2)Build and install the latest cygwin dll and tools from cvs 3)Checkout the 3.1 tree from gcc cvs server 4)Run a vanilla configuration 5)Observe what happens on that line... Of course, it might just be time for me to reinstall windows me, but perhaps someone can confirm/deny my observations on another install of windows me. Cheers, Nicholas --- Russ Jorgensen wrote: > Was anyone able to resolve this issue? A few weeks > ago I posted about poor bash performance with "while > read" loops. Maybe this is the same issue... > > Anyway, I hadn't upgraded my cygwin1.dll for quite a > long time, but when I did, some of my shell scripts > started to have horrible performance. I tracked it > down to the "while read" loops. I wrote the following > benchmark shell script to see how bad the problem > really is. On my PII-333 running Win-ME, I get the > following results: > > # time ./doit 1 > > real 0m3.555s > user 0m0.000s > sys 0m0.000s > > # time ./doit 2 > > real 0m22.870s > user 0m0.000s > sys 0m0.000s > > When I run the same benchmark on a linux machine, I > don't get nearly as big a difference between the two > runs. > > It would be really great if one of the crack > programmers who work on cygwin could look into this. > I imagine that everyone who uses cygwin would > appreciate a performance boost! > > Anyway, here's the benchmark shell script. Thanks. > > -Russ > > #!/bin/bash > > # > # benchmark piping into "while read" > # > # "doit 1" is the "first pass" which benchmarks > # generating output with the nested for-loops > # > # "doit 2" is the "second pass" which adds on the > # "while read" loop > # > > # check usage > if test $# -ne 1; then > echo "usage: doit {1|2}" > exit 1 > fi > > # first pass: generate a bunch of output > for i in 1 2 3 4 5 6 7 8 9 0; do > for j in 1 2 3 4 5 6 7 8 9 0; do > for k in 1 2 3 4 5 6 7 8 9 0; do > for l in 1 2 3 4 5 6 7 8 9 0; do > echo hi > done > done > done > done | > > # second pass: the "while read" loop > if test $1 != 2; then > cat - > /dev/null > else > while read JUNK; do > A=1 > done > fi > > > > > At 11:42 PM 5/29/2002, Johnny D wrote: > > > > >I am not sure when this bug might have been > > introduced. I have an app which deals with multiple > > socket descriptors for reads and writes. It uses the > > select() function call from cygwin library. I took > > the same source code - compiled it with a newer > > installaion of Cygwin (1.3.10 based). I see that > > the select call seems to be getting stuck at points > > and so the performance of my server has dropped thru > > the floor. > > >I dont have an older installation currently that I > > can use and I couldnt figure out how to get an older > > version of your package from the cygwin website. I > > urgently need to get this resolved. Prefer to have > > the complete Cygwin package dating close to Dec 2000 > > (whcih is the last best known version of Cygwin that > > is known to work fine for me). Can someone point me > > to the right location from which I can install the > > same? > > >Or if this is a known issue, does anyone have a > > patch I could use? > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/