From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: Peter Schay Message-ID: <3AF962AB.10E95C78@pobox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <20010509132356.1923D199F0@mail.cse.psu.edu> Subject: Re: [9fans] env walk Date: Wed, 9 May 2001 15:45:14 +0000 Topicbox-Message-UUID: 9c6f0ed2-eac9-11e9-9e20-41e7f4b1d025 As far as I can tell, the loop I proposed in envwalk() is a linear search to walk to an environment variable. The devwalk+envgen algorithm is n squared because the loop in envgen is nested within the loop in devwalk. It's amazing how that tiny little loop in envgen can eat up time! Pete presotto@plan9.bell-labs.com wrote: > > All the devices that use devwalk have n squared behavior. It wasn't > supposed to be a problem because n isn't supposed to be large for them. > I agree that it's short sighted for something with potentially many files > like #e. Your solution is also O(n**2), though the constant > is much smaller (no devdir inside the loop). I'll replace the devwalk > with your search and put it on the next update wrap. > > Also, on network performance, we played a bunch with TCP speed after > Dong Lin showed us how slow we were. Last we tested our TCP stack, > we came out somewhere between Linux and FreeBSD in speed between 2 > 500 MHZ Pentiums on a 100meg ether. That's partially why loopbackmedium > appeared, to see how much was stack and how much driver. I'll run > a new set of tests in a few weeks and post when I'm done. > Since both all 3 OS's are moving targets, the validity > of the tests is transient. Sic transit perfunctio.