Re: [9fans] env walk

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

You're right, it's spurious, it does use #e, but this is getting tedious.
I bugged rc.  It really doesn't reread the env's when it starts a new command,
only when rc itself is started.  The time in his example was completely accounted for
by setting the variables, not by forking rc as he claimed.

This isn't to say that if you create a new a few hundred variables and
then restart rc you won't get the variables reread, but that's not
what the example was doing.

I'm not saying that this isn't a problem.  I did two kernel mk's in
a row, one with only the usual dozen or so env's and one with 400+ env's.
The latter was interminable since rc is getting exec'd for every rule.
The ratio of times was about 7 to 1.  With the fix it goes down to
1.75 to 1.  It's the result of the n**3 going to n**2.  Not perfect
but, given that we rarely have that many env's, livable.

[-- Attachment #2: Type: message/rfc822, Size: 1616 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] env walk
Date: Thu, 10 May 2001 14:39:40 +0100
Message-ID: <20010510133208.2132F199E7@mail.cse.psu.edu>

> By the way, it's setting all the env's in your example that takes the
> time, not forking in rc.  Rc doesn't reread the /env's.  If you
> do an iostats on the example you'll see no opens of /env after
> setting the vars:

that's a bit spurious, i'm afraid, because rc opens #e directly so
iostats can't see those accesses.

given that rc does read all the environment variables when it starts
up, i think it's quite likely it's spending a fair amount of time doing
so...

  rog.