From mboxrd@z Thu Jan  1 00:00:00 1970
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] env walk
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-jpffrqmuymeakhgogcujdzwbxa"
Message-Id: <20010510144140.6A7D8199E7@mail.cse.psu.edu>
Date: Thu, 10 May 2001 10:41:38 -0400
Topicbox-Message-UUID: 9d886dc2-eac9-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-jpffrqmuymeakhgogcujdzwbxa
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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.

--upas-jpffrqmuymeakhgogcujdzwbxa
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu May 10 09:33:24 EDT 2001
Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu May 10 09:33:22 EDT 2001
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id CFCB2199F9; Thu, 10 May 2001 09:33:09 -0400 (EDT)
Received: from presto.hci-net (unknown [62.254.170.97])
	by mail.cse.psu.edu (CSE Mail Server) with SMTP id 2132F199E7
	for <9fans@cse.psu.edu>; Thu, 10 May 2001 09:32:08 -0400 (EDT)
To: 9fans@cse.psu.edu
Subject: Re: [9fans] env walk
From: rog@vitanuova.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20010510133208.2132F199E7@mail.cse.psu.edu>
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.1
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
Date: Thu, 10 May 2001 14:39:40 +0100

> 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.

--upas-jpffrqmuymeakhgogcujdzwbxa--