This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Very slow Cygwin startup on Windows 7


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

Attachment: pgp4Rdiwk8BMz.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]