[ANNOUNCEMENT] TEST RELEASE: Cygwin 1.7.35-0.4
Wed Feb 25 21:04:00 GMT 2015
On Feb 25 21:02, Achim Gratz wrote:
> Corinna Vinschen writes:
> > This release introduces a rewrite of the functions being the main
> > culprit for the slowness of fetching account information from AD.
> > There are still a few potential ways to hone the results, but code-wise
> > there isn't a lot left to do anymore.
> I'll reply here…
> I've just tested the latest snapshot (aka the 0.4 release) via VPN. The
> basic test is starting a mintty from a cmd prompt and have mintty run
> some program depending on the test. I run two tests, one is just an
> "echo test" which uses the builtin echo of the shell that mintty just
> fired up, the other does a "git status". Connected via LAN the echo
> tests take all under a second now save for a few excursion when I didn't
> start cygwrunserv that were around 1.5s. The git test takes a bit
> longer depending on whether I start it on a network share or a local
> directory, but completes in under 2s.
> Now, connecting via the VPN and not running cygserv I get 2s for the
> echo test and 47/42/6 seconds for git status on two different network
> shares and a local repository (these repositories are all fairly small,
> just some local configuration stuff). With cygserv running, these times
> change to 1/49/5/5 seconds (yes, it took two seconds longer on one of
> the network shares).
> As it happens, I can force the VPN to connect almost exactly from the
> other side of the globe, which will produce a long roundtrip time
> (unless you are having a satellite link in there somewhere or really
> stupid routing it can't get much worse than that). In this case, with
> cygserv running I get 15/840/40/85 seconds. Without cygserv, this
> becomes 39/789/-/95 (I skipped one of the network shares for this test).
> Again there's one network share that had better performance for the git
> test without cygserv. Another interesting bit is that the echo test
> time actually depended on whether the working directory was on a network
> share (resulting in 39 seconds) or on the local drive (where it only
> took 26 seconds).
> So, those changes in the latest snapshot look good from that perspective
> and the remaining delays, at least with cygserv running are in any case
> not attributable to the LDAP integration. I don't have an old Cygwin
> installation o that machine anymore, but the results w/ cygserv on the
> long latency link match my experience of using that long latency link
> "for real" about a year ago.
I'm still a bit confused by the results. What "delays" are we looking
at if they are not attributable to LDAP? Are they "expected" delays
or is that something which is new now? If it's new, is there a simple
testcase we can use for further debugging, preferredly one with a
single executable showing a certain, debuggable behaviour. This should
ideally start with an strace to isolate the problem, and then we can
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Cygwin