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? > > Sure.
Thanks for helping debugging, Dennis. ====================================================================== 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. ====================================================================== 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 ==> 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpGNKnNdUA1t.pgp
Description: PGP signature
