Mail Archives: cygwin/2015/02/20/11:20:55
--6pjpgtPchv3bUQQn
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Feb 19 19:04, Dennis Hagarty (dehagart) wrote:
> >It would be pretty helpful to get an idea what's so slow in your case.
> >Either you get ADInsight working, or... is it ok if I send you a link
> >to a debug-augmented DLL via PM?
>=20
> Sure.
Thanks for helping debugging, Dennis.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
tl;dr synopsis: There are new snaphots at https://cygwin.com/snapshots/
which introduce a restriction of the time fetching group information
at startup is allowed to take (300ms). Please give'em a try.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I asked Dennis to run Cygwin's "echo" three times from CMD, no cygserver
running, to get some timing values and to be able to observer OS caching
effects.
First of all, the first call of echo took a bit longer than the followup
calls, because fetching the machine and domain info took longer. The
info is supposed to be cached on the local machine, but the info is
refreshed in a 15 minute cycle or something like that. This first call
to fetch this info took 0.3 secs, so maybe your local machine was just
in that refresh cycle. The same thing in the followup echo calls only
took 9 and 7ms. Clearly a caching effect.
However, fetching every single group from your token, information which
should be locally available or at least should be quickly available via
the global catalog, takes roughly 40 to 50 ms each. This adds up quickly
to the 1.4 secs you see as delay running an echo here.
To explain, the idea to fetch all the group info from your user token
was to make sure that the first process in a process tree already had
the entire set of your groups available. This was based on a complaint
that calling `id' could take a long time.
However, on second thought, this looks like a terrible idea. 40 to 50ms
per group is a hell of a lot of time when fetching lots of group info.
For comparison, in my tiny home network, fetching this info takes
between 2 and 5 ms per group :}
In a second test run I asked Dennis to give me the timing of a startup
and calling `id' with cygserver running.
The results:
- Without cygserver:
Shell startup: 1.5s
Calling `id': 0.1s
Calling `id' again: 0.1s
- With cygserver:
Shell startup: 0.1s
Calling `id': 1.5s
Calling `id' again: 0.1s
The reason for this behaviour is the difference in startup:
- When cygserver is not running, the startup fetches the information for
all groups in the user token. Thus the first process (mintty when
clicking on the desktop icon) takes long, and followup processes have
the cached information at their leisure.
- When cygserver is running, the startup does not fetch the group
information (relying on cygserver instead). Thus, the first call to
`id' does it instead and takes the long time. Afterwards, the
information is cached in cygserver and the next call to `id' is fast.
The first idea was to stop fetching the group info at startup
completely. But that has the side effect of having an always slow `id'
call, if cygserver isn't running, so it's not exactly clear to me if
that's not just frying pan =3D=3D> fire.
So what I did now for testing is to add a timer. If cygserver is not
running, the startup procedure still fetches the group info from the
user's token... but if it couldn't finish the job within 300ms, it
just stops collecting this information and moves on.
That should have a "mixed" effect in slow scenarios. The startup will
not take longer than about 300ms, so it's comparatively fast from a
human perspective, but it will not entirely give up on collecting group
information so subsequent calls fetching group info will be faster.
The value itself, 300ms, is disputable, of course. I just chose it from
my gut feeling. If this method is a usable compromise, maybe 400 or
500ms is good enough, I don't know.
I uploaded new developer snapshots containing this change to
https://cygwin.com/snapshots/
Please give them a try.
Thanks,
Corinna
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--6pjpgtPchv3bUQQn
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJU517IAAoJEPU2Bp2uRE+g15sP/05fcAfpP+VsaKqg9OTshkKo
xidaFOQ28OMSnmNifPWMzRGtrG8+qwgl6TSYKE+fqxlmMe/rdA7A5U5P1vd0+lFH
HraKCL90NQSkqocM2NlsebrglbGM/UUANSx59RVUae4zho2/Wk+Oc2GpNX5OMw8P
1wPUK3RQ1P9Nk/0aK4SgAKGcR+es/OlBmtdm4pzl5keDJwyg4uFobYKqaEM11MSW
yTbLZl+fby04B/ww8wNHC586iUUpPmjmSkNLIHJyq7V2Gb8/dJDGkOHEPf1Oi9dw
VXq0C1qKBc2VljAqLOI68JZWo9O4YuAPaj9kQRI5xNCWs3qcohaAiE97Egr/3Co/
XNYPqFYy7GvgpLKoeSvwO5LfX6wfx2a/PMd4V3FCvn9SAHKdb3voLJwRccj4n3Yc
U9Y8wt3HvKwEJYIC0PIxqvfKSmx8nCw+ID1qOaRnPeSg06cZLZOwNZPPJ7eQBIzq
SH4izdG+72F+DJcRWk0XajfPiInUn2qDcJNaC0d6G3VkQPMVMlHyJps292dubHnS
xrE0b5LQv72JY/dcVM2MxFodRBUGvtfwFAE7onDKeAE5qkRLjev3tOxgNZQd+ZOL
ERaFxq8eryfU5GZa2g8m+ZaJA2JtK8Y3AjbLG/IMq/ynJgn6ijaiIS0ZCHgcNJSi
v5ysLn4/h3gpy684jYbX
=N0sD
-----END PGP SIGNATURE-----
--6pjpgtPchv3bUQQn--
- Raw text -